ডোমেন / অধ্যবসায় মডেল বিচ্ছিন্নতা সাধারণত এই বিশ্রী হয়?


13

আমি ডোমেন-ড্রাইভড ডিজাইন (ডিডিডি) এর ধারণাগুলিতে ডুব দিচ্ছি এবং বিশেষত ডোমেন এবং অধ্যবসায়ের মডেলকে বিচ্ছিন্ন করার বিষয়ে কিছু নীতিগুলি অদ্ভুত বলে মনে করেছি। এখানে আমার বোধগম্যতা:

  1. অ্যাপ্লিকেশন স্তরের একটি পরিষেবা (একটি বৈশিষ্ট্য সেট সরবরাহ করে) কোনও রেপোজিটরি থেকে ডোমেন অবজেক্টগুলিকে অনুরোধ করে যাতে এটির কার্য সম্পাদন করা প্রয়োজন।
  2. এই ভাণ্ডারটির কংক্রিট বাস্তবায়ন স্টোরেজ থেকে ডেটা এনেছে যার জন্য এটি প্রয়োগ করা হয়েছিল
  3. পরিষেবাটি ডোমেন অবজেক্টকে বলে, যা ব্যবসায় যুক্তি সংযুক্ত করে, এমন কিছু কার্য সম্পাদন করে যা তার অবস্থার পরিবর্তন করে।
  4. পরিষেবাটি পরিবর্তিত ডোমেন অবজেক্টটি অবিরত রাখতে সংগ্রহস্থলকে বলে।
  5. সঞ্চয়স্থানে ডোমেন অবজেক্টটিকে স্টোরেজে সম্পর্কিত প্রতিনিধিত্ব করতে ম্যাপ করতে হবে।

ফ্লো ইলাস্ট্রেশন

এখন, উপরের অনুমানগুলি দেওয়া, নিম্নলিখিতগুলি বিশ্রী মনে হচ্ছে:

বিজ্ঞাপন 2 .:

ডোমেন মডেলটি পুরো ডোমেন অবজেক্টটিকে (সমস্ত ক্ষেত্র এবং রেফারেন্স সহ) লোড করবে বলে মনে হচ্ছে, এমনকি যদি এটির অনুরোধ করা ফাংশনের জন্য তাদের প্রয়োজন না হয়। অন্যান্য ডোমেন অবজেক্টগুলি রেফারেন্স করা থাকলে পুরোপুরি লোড করা সম্ভব নাও হতে পারে, যদি না আপনি সেই ডোমেন অবজেক্টগুলিকে এবং তারা যে সমস্ত অবজেক্টগুলিকে রেফারেন্স দেয় এবং লোড না করে এবং ততক্ষণ চালিয়ে যায়। অলস লোডিংয়ের বিষয়টি মাথায় আসে, এর অর্থ হল যে আপনি আপনার ডোমেন অবজেক্টগুলি অনুসন্ধান করা শুরু করছেন যা প্রথমে সংগ্রহস্থলের দায়িত্ব হওয়া উচিত।

এই সমস্যাটি দেওয়া, ডোমেন অবজেক্টগুলি লোড করার "সঠিক" পদ্ধতিতে প্রতিটি ব্যবহারের ক্ষেত্রে একটি ডেডিকেটেড লোডিং ফাংশন রয়েছে বলে মনে হচ্ছে। এই উত্সর্গীকৃত ফাংশনগুলি তখন কেবল তাদের জন্য নকশাকৃত ব্যবহারের ক্ষেত্রে প্রয়োজনীয় ডেটা লোড করবে। বিশৃঙ্খলাটি এখানে আসে: এখানে প্রথমে আমাকে সংগ্রহস্থলের প্রতিটি প্রয়োগের জন্য প্রচুর পরিমাণে লোডিং ফাংশন বজায় রাখতে হবে এবং ডোমেন অবজেক্টগুলি nullতাদের ক্ষেত্রগুলি বহনকারী অসম্পূর্ণ রাজ্যে শেষ হবে । পরেরটির প্রযুক্তিগতভাবে সমস্যা হওয়া উচিত নয় কারণ যদি কোনও মান লোড না করা হয় তবে যেভাবে এটির জন্য অনুরোধ করা কার্যকারিতা দ্বারা এটির প্রয়োজন হবে না। তবুও এটি বিশ্রী এবং সম্ভাব্য বিপত্তি।

বিজ্ঞাপন 3 .:

কোনও ডোমেন অবজেক্ট কীভাবে নির্মাণের ক্ষেত্রে স্বতন্ত্রতা বাধার বিষয়টি যাচাই করবে যদি এটির ভাণ্ডারের কোনও ধারণা না থাকে? উদাহরণস্বরূপ, আমি যদি Userএকটি অনন্য সামাজিক সুরক্ষা নম্বর (যা দেওয়া হয়) দিয়ে একটি নতুন তৈরি করতে চাইতাম , তবে প্রাথমিকভাবে দ্বন্দ্বটি সংগ্রহস্থলটিকে অবজেক্টটি সংরক্ষণ করতে বলার পরে ঘটবে, কেবলমাত্র যদি ডাটাবেসে কোনও স্বতন্ত্রতা বাধা থাকে। অন্যথায়, আমি Userপ্রদত্ত সামাজিক সুরক্ষা সহ একটি সন্ধান করতে এবং একটি নতুন তৈরি করার আগে, এটি উপস্থিত থাকলে কোনও ত্রুটিটি রিপোর্ট করতে পারি। তবে তখন সীমাবদ্ধ চেকগুলি পরিষেবাতে থাকবে এবং তারা যেখানে ডোমেন অবজেক্টে থাকবে না। আমি কেবল বুঝতে পেরেছি যে ডোমেন অবজেক্টগুলিকে বৈধতার জন্য খুব ভালভাবে (ইনজেকশনের) সংগ্রহস্থলগুলি ব্যবহারের অনুমতি দেওয়া হয়।

বিজ্ঞাপন 5 .:

আমি ডোমেন অবজেক্টগুলিকে সরাসরি আন্ডারলিংয়ের ডেটা সংশোধন করার তুলনায় একটি কার্য-নিবিড় প্রক্রিয়া হিসাবে একটি স্টোরেজ ব্যাকএন্ডে ডোমেন অবজেক্টগুলির ম্যাপিংটি উপলব্ধি করি। অবশ্যই, এটি ডোমেন কোড থেকে কংক্রিট স্টোরেজ বাস্তবায়ন ডিক্লুপ করার জন্য একটি প্রয়োজনীয় শর্ত। যাইহোক, সত্যিই কি এটি এত উচ্চ ব্যয় হয়?

আপনার জন্য ম্যাপিং করতে স্পষ্টতই আপনার কাছে ORM সরঞ্জামগুলি ব্যবহার করার বিকল্প রয়েছে। এগুলির জন্য আপনাকে সাধারণত ওআরএমের বিধিনিষেধ অনুসারে ডোমেন মডেলটি ডিজাইন করার প্রয়োজন হয়, বা এমনকি ডোমেন থেকে পরিকাঠামো স্তরতে নির্ভরতা প্রবর্তন করে (উদাহরণস্বরূপ ডোমেন অবজেক্টগুলিতে ওআরএম টীকা ব্যবহার করে)। এছাড়াও আমি পড়েছি যে ওআরএমগুলি একটি যথেষ্ট পরিমাণে গণনামূলক ওভারহেড প্রবর্তন করে।

নোএসকিউএল ডাটাবেসের ক্ষেত্রে, যার জন্য খুব কমই কোনও ওআরএম-জাতীয় ধারণা বিদ্যমান, আপনি কীভাবে ডোমেন মডেলগুলিতে কোন বৈশিষ্ট্য পরিবর্তিত হয়েছিলেন তা ট্র্যাক করবেন save()?

সম্পাদনা : এছাড়াও, ডোমেন অবজেক্টের স্থিতি (যেমন প্রতিটি ক্ষেত্রের মান) অ্যাক্সেসের জন্য কোনও সংগ্রহস্থলের জন্য, ডোমেন অবজেক্টটির অভ্যন্তরীণ অবস্থা প্রকাশ করতে হবে যা এনক্যাপসুলেশনটি ভেঙে দেয়।

সাধারণভাবে:

  • লেনদেনের যুক্তি কোথায় যাবে? এটি অবশ্যই দৃistence়তা নির্দিষ্ট। কিছু স্টোরেজ অবকাঠামো এমনকি লেনদেনকে মোটেই সমর্থন করে না (যেমন মেমরি মক রিপোজিটরিগুলি)।
  • একাধিক অবজেক্টগুলিকে সংশোধনকারী বাল্ক অপারেশনের জন্য, আমাকে কি প্রতিটি বস্তু পৃথকভাবে লোড, সংশোধন এবং সংরক্ষণ করতে হবে যাতে অবজেক্টের এনক্যাপসুলেটেড বৈধতা যুক্তির মাধ্যমে যেতে হবে? এটি সরাসরি ডাটাবেসে একটি একক ক্যোয়ারী কার্যকর করার বিরোধিতা করে।

আমি এই বিষয়ে কিছু স্পষ্টির প্রশংসা করব। আমার অনুমানগুলি কি সঠিক? যদি তা না হয় তবে এই সমস্যাগুলি মোকাবেলার সঠিক উপায় কী?


1
ভাল পয়েন্ট এবং প্রশ্ন, আমি সেগুলিতেও আগ্রহী। এক পক্ষের নোট - আপনি যদি সামগ্রিকভাবে সঠিকভাবে মডেলিং করছেন তার অর্থ এই যে কোনও নির্দিষ্ট অস্তিত্বের সময়ে, সমষ্টিগত উদাহরণটি বৈধ অবস্থায় থাকতে হবে - এটি সমষ্টিটির মূল পয়েন্ট (এবং কোনও সংমিশ্রণ একটি সংস্থার ধারক হিসাবে ব্যবহার না করা)। এর অর্থ হ'ল ডিবি ডেটা সামগ্রিক রূপটি পুনরুদ্ধার করতে, সাধারণত সংগ্রহস্থলকে নির্দিষ্ট কন্সট্রাক্টর এবং মিউটেশন অপারেশনগুলির সেট ব্যবহার করতে হত, এবং কোনও ওআরএম কীভাবে স্বয়ংক্রিয়ভাবে এই অপারেশনগুলি করতে পারে তা জানতে পারে know ।
দুশান

2
এর চেয়েও হতাশার বিষয় হ'ল আপনার মতো প্রশ্নগুলি প্রায়শই প্রায়শই জিজ্ঞাসা করা হয় তবে আমার জ্ঞানের কাছে - গ্রন্থ এবং সংগ্রহস্থলগুলি বাস্তবায়নের জেরো উদাহরণ রয়েছে
দুসান

উত্তর:


5

আপনার প্রাথমিক বোঝাপড়াটি সঠিক এবং আপনি যে আর্কিটেকচারটি স্কেচ করেছেন তা ভাল এবং ভালভাবে কাজ করে।

রেখাগুলির মধ্যে পড়া মনে হচ্ছে আপনি প্রোগ্রামিংয়ের আরও একটি ডাটাবেস কেন্দ্রিক সক্রিয় রেকর্ড শৈলী থেকে এসেছেন? একটি কার্যকরী বাস্তবায়নে যেতে আমি বলব আপনার প্রয়োজন to

1: ডোমেন অবজেক্টগুলিকে পুরো অবজেক্ট গ্রাফটি অন্তর্ভুক্ত করতে হবে না। উদাহরণস্বরূপ আমি থাকতে পারে:

public class Customer
{
    public string AddressId {get;set;}
    public string Name {get;set;}
}

public class Address
{
    public string Id {get;set;}
    public string HouseNumber {get;set;
}

ঠিকানা এবং গ্রাহকের কেবল একই সমষ্টিটির অংশ হওয়া দরকার যদি আপনার কিছু যুক্তি থাকে যেমন, "গ্রাহকের নাম কেবলমাত্র বাড়ির নাম হিসাবে একই অক্ষর দিয়ে শুরু করতে পারে"। আপনি অলস লোড এবং অবজেক্টের 'লাইট' সংস্করণ এড়াতে ঠিক বলেছেন।

2: স্বতন্ত্রতার সীমাবদ্ধতাগুলি সাধারণত ডোমেন অবজেক্টের নয়, স্টোরের পরিমার্জন হয়। ডোমেন অবজেক্টগুলিতে ভান্ডারগুলি ইনজেক্ট করবেন না, এটি সক্রিয় রেকর্ডে ফিরে যাওয়া, যখন পরিষেবাটি সংরক্ষণের চেষ্টা করে তখন কেবল ত্রুটি।

ব্যবসায়ের নিয়মটি "একই সামাজিক সুরক্ষাসংখ্যার সাথে ব্যবহারকারীর কোনও দুটি উদাহরণ একই সময়ে একই সাথে থাকতে পারে না"

এটি সেই একই ভান্ডারের উপর বিদ্যমান নয়।

3: পৃথক সম্পত্তি আপডেট পদ্ধতির পরিবর্তে সংগ্রহস্থলগুলি লেখা কঠিন নয়। আসলে, আপনি দেখতে পাবেন যে কোনওভাবেই আপনার কাছে একই কোড রয়েছে। আপনি এটি কোন শ্রেণিতে রেখেছেন তা ঠিক।

এই দিনগুলিতে ORM গুলি সহজ এবং আপনার কোডে কোনও অতিরিক্ত বাধা নেই। এটি বলার পরে, ব্যক্তিগতভাবে আমি কেবল এসকিউএল হ্যান্ড ক্র্যাঙ্ক করতে পছন্দ করি। এটি এতটা কঠিন নয়, আপনি কখনই ওআরএম বৈশিষ্ট্যগুলি নিয়ে কোনও সমস্যায় পড়ে না এবং যেখানে প্রয়োজন সেখানে অনুকূলিত করতে পারেন।

আপনি যখন সংরক্ষণ করেছিলেন তখন কোন বৈশিষ্ট্য পরিবর্তিত হয়েছিল সে সম্পর্কে সত্যই কোনও খবর রাখার দরকার নেই। আপনার ডোমেন অবজেক্টগুলি ছোট রাখুন এবং কেবল পুরানো সংস্করণটি ওভাররাইট করুন।

সাধারণ প্রশ্ন

  1. লেনদেনের লজিকগুলি সংগ্রহস্থলটিতে চলে যায়। তবে এর কিছু থাকলেও আপনার বেশি হওয়া উচিত নয়। নিশ্চিতভাবে আপনার কিছু টেবিলে দরকার আছে যাতে আপনি সামগ্রিকভাবে শিশু সামগ্রীর উপর রাখছেন তবে সেটি পুরোপুরি SaveMyObject সংগ্রহস্থল পদ্ধতির মধ্যে আবদ্ধ হবে।

  2. বাল্ক আপডেট। হ্যাঁ আপনার পৃথকভাবে প্রতিটি বস্তুর পরিবর্তন করা উচিত তবে বাল্ক আপডেট করার জন্য কেবল আপনার সংগ্রহস্থলে একটি SaveMyObjects (তালিকা অবজেক্ট) পদ্ধতি যুক্ত করুন।

    আপনি চাইছেন যে ডোমেন অবজেক্ট বা ডোমেন পরিষেবাটি যুক্তিটি ধারণ করে। না ডাটাবেস। তার মানে আপনি কেবলমাত্র "আপডেট গ্রাহক সেট নাম = x যেখানে y" করতে পারবেন না কারণ আপনি যখন গ্রাহক অবজেক্টটি জানেন বা গ্রাহকআপডেটসেসওয়ার্স নাম পরিবর্তন করেন তখন 20 টি ভিন্ন ভিন্ন জিনিস করেন।


দুর্দান্ত উত্তর। আপনি একেবারে ঠিক বলেছেন, আমি কোডিংয়ের একটি সক্রিয় রেকর্ড শৈলীতে অভ্যস্ত, এই কারণেই প্রথম দেখায় ভান্ডারগুলির প্যাটার্নটি বিজোড় বলে মনে হয়। তবে, "পাতলা" ডোমেন অবজেক্টগুলি ( AddressIdপরিবর্তে Address) ওও নীতিগুলি বিরোধী করে না?
ডাবল এম

না, আপনার এখনও একটি ঠিকানা অবজেক্ট রয়েছে এটি কেবল গ্রাহকের সন্তান নয়
ইওয়ান

পরিবর্তন ট্র্যাকিং ছাড়া বিজ্ঞাপন বস্তুর ম্যাপিং softwareengineering.stackexchange.com/questions/380274/...
ডাবল এম

2

সংক্ষিপ্ত উত্তর: আপনার বোধগম্যতা সঠিক এবং আপনি যে প্রশ্নগুলি বৈধ সমস্যার দিকে নির্দেশ করেছেন সেগুলির সমাধানগুলি সরাসরি সামনে বা সর্বজনস্বীকৃত নয়।

পয়েন্ট 2 .: (সম্পূর্ণ বস্তুর গ্রাফ লোড করা হচ্ছে)

আমি প্রথমে এটি চিহ্নিত করার জন্য নয় যে ওআরএম সবসময় ভাল সমাধান নয়। মূল সমস্যাটি হ'ল যে ওআরএম প্রকৃত ব্যবহারের ক্ষেত্রে কিছুই জানে না, তাই কী লোড করবেন বা কীভাবে অনুকূল করা যায় সে সম্পর্কে তাদের কোনও ধারণা নেই। এটা একটা সমস্যা.

যেমনটি আপনি বলেছেন, সুস্পষ্ট সমাধান হ'ল প্রতিটি ব্যবহারের ক্ষেত্রে দৃ pers়তা পদ্ধতি থাকা। তবে আপনি যদি এখনও এর জন্য কোনও ওআরএম ব্যবহার করেন, তবে ORM আপনাকে সমস্ত কিছু ডেটা-অবজেক্টে প্যাক করতে বাধ্য করবে। যা সত্যই বস্তু-ভিত্তিক না হওয়া ছাড়াও, কিছু ব্যবহারের ক্ষেত্রে এটি সেরা নকশা নয়।

আমি যদি কেবল কিছু রেকর্ড বাল্ক-আপডেট করতে চাই? কেন আমার সমস্ত রেকর্ডের জন্য কোনও অবজেক্টের উপস্থাপনের প্রয়োজন হবে? প্রভৃতি

সুতরাং এর সমাধানটি হ'ল ব্যবহারের ক্ষেত্রে কোনও ওআরএম ব্যবহার না করা যার জন্য এটি উপযুক্ত নয়। "প্রাকৃতিকভাবে" ব্যবহারের ক্ষেত্রে যেমনটি হয় তেমন প্রয়োগ করুন, যা কখনও কখনও ডেটা নিজেই (ডেটা-অবজেক্টস) অতিরিক্ত "বিমূর্ততা" বা "টেবিলগুলি" (সংগ্রহশালা) এর বিমূর্ততার প্রয়োজন হয় না।

অর্ধ-ভরা ডেটা অবজেক্ট থাকা বা "আইডস" এর সাথে অবজেক্টের রেফারেন্সগুলি প্রতিস্থাপন করা সর্বোত্তমভাবে নকশাগুলি নয়, ভাল নকশাগুলি নয়, যেমন আপনি উল্লেখ করেছেন।

পয়েন্ট 3 .: (সীমাবদ্ধতা পরীক্ষা করা)

যদি অধ্যবসায়টি বিমূর্ত না করা হয় তবে প্রতিটি ব্যবহারের ক্ষেত্রে এটি সহজেই যে কোনও প্রতিবন্ধকতা চায় তা যাচাই করে নিতে পারে। "সংগ্রহস্থল" অবজেক্টগুলি জানে না এমন প্রয়োজনীয়তা সম্পূর্ণ কৃত্রিম এবং প্রযুক্তির কোনও সমস্যা নয়।

পয়েন্ট 5 .: (ওআরএম)

অবশ্যই, এটি ডোমেন কোড থেকে কংক্রিট স্টোরেজ বাস্তবায়ন ডিক্লুপ করার জন্য একটি প্রয়োজনীয় শর্ত। যাইহোক, সত্যিই কি এটি এত উচ্চ ব্যয় হয়?

না, তা হয় না। অধ্যবসায়ী হওয়ার আরও অনেক উপায় রয়েছে। সমস্যাটি হ'ল ওআরএমকে সর্বদা ব্যবহারের "" সমাধান হিসাবে দেখা হয় (কমপক্ষে রিলেশনাল ডাটাবেসের জন্য)। কোনও প্রকল্পে কিছু ব্যবহারের ক্ষেত্রে এটি ব্যবহার না করার পরামর্শ দেওয়ার চেষ্টা করা নিরর্থক এবং নিজেই কখনও কখনও এমনকি অসম্ভব অসম্ভব ORM এর উপর নির্ভর করে, যেহেতু ক্যাশে এবং দেরী-কার্যকরকরণ কখনও কখনও এই সরঞ্জামগুলি দ্বারা ব্যবহৃত হয়।

সাধারণ প্রশ্ন 1: (লেনদেন)

আমি মনে করি না এর একটি একক সমাধান আছে। যদি আপনার নকশাটি অবজেক্ট ভিত্তিক হয় তবে প্রতিটি ব্যবহারের ক্ষেত্রে "শীর্ষ" পদ্ধতি থাকবে। লেনদেন করা উচিত।

অন্য কোনও সীমাবদ্ধতা সম্পূর্ণ কৃত্রিম।

সাধারণ প্রশ্ন 2 .: (বাল্ক অপারেশন)

একটি ORM সহ, আপনি (বেশিরভাগ ORMs সম্পর্কে আমি জানি) স্বতন্ত্র বস্তুর মধ্য দিয়ে যেতে বাধ্য হয়। এটি সম্পূর্ণ অপ্রয়োজনীয় এবং সম্ভবত আপনার নকশা যদি ওআরএম দ্বারা বাঁধা না থাকে would

এসকিউএল থেকে "যুক্তি" আলাদা করার প্রয়োজনীয়তা ওআরএম থেকে আসে। তারা আছে , কারণ তারা এটা সমর্থন করতে পারে না, যে বলে। এটি সহজাতভাবে "খারাপ" নয় is

সারসংক্ষেপ

আমার ধারণাটি হ'ল ওআরএম সবসময় কোনও প্রকল্পের জন্য সেরা হাতিয়ার হয় না এবং এমনকি যদি হয় তবে এটি কোনও প্রকল্পের সমস্ত ব্যবহারের ক্ষেত্রে সেরা হওয়ার সম্ভাবনা খুব কম।

একইভাবে, ডিডিডি-র ডেটাবোজেক্ট-রেপোজিটরি বিমূর্ততা সর্বদা সেরা হয় না। আমি এমনকি এতদূর যেতে চাই যে, তারা খুব কমই অনুকূল নকশা।

এটি আমাদের কোনও আকারের-ফিট-সব সমাধান ছাড়েনি, সুতরাং প্রতিটি ব্যবহারের ক্ষেত্রে পৃথক পৃথক ব্যবহারের সমাধান সম্পর্কে আমাদের ভাবতে হবে, এটি সুসংবাদ নয় এবং স্পষ্টতই আমাদের কাজকে আরও কঠিন করে তোলে :)


সেখানে খুব আকর্ষণীয় বিষয়, আমার অনুমানগুলি নিশ্চিত করার জন্য আপনাকে ধন্যবাদ। আপনি বলেছিলেন অধ্যবসায় করার আরও অনেক উপায় আছে। আপনি গ্রাফ ডাটাবেসগুলির সাথে (কোনও ওআরএম নেই) ব্যবহার করার জন্য কোনও পারফরম্যান্ট ডিজাইনের ধরণটি সুপারিশ করতে পারেন, যা এখনও পিআই সরবরাহ করবে?
ডাবল এম

1
আমি আসলে প্রশ্ন করব যে আপনার প্রথম স্থানটিতে বিচ্ছিন্নতা (এবং কোন ধরণের) প্রয়োজন। প্রযুক্তি প্রতি প্রতি বিচ্ছিন্নকরণ (যেমন ডাটাবেস, ইউআই, ইত্যাদি) ডাটাবেস প্রযুক্তির কিছুটা সহজ প্রতিস্থাপনের সুবিধার্থে আপনি স্বয়ংক্রিয়ভাবে "বিশ্রীতা" এড়াতে পারেন যা আপনি এড়াতে চাইছেন। ব্যয়টি ব্যবসায়ের যুক্তিগুলির আরও একটি কঠিন পরিবর্তন যেহেতু স্তরগুলি ছড়িয়ে পড়ে। অথবা আপনি ব্যবসায়িক ক্রিয়াকলাপগুলিতে বিভক্ত হয়ে যেতে পারেন, যা ডাটাবেস পরিবর্তন করা আরও শক্ত করে, তবে যুক্তি পরিবর্তন করা সহজ। আপনি আসলে কোনটি চান?
রবার্ট ব্রুটিগাম

1
আপনি যদি কেবলমাত্র ডোমেনটি মডেল করেন (যেমন ব্যবসায়িক ফাংশন) এবং আপনি ডাটাবেসটি বিমূর্ত না করে (রিলেশনাল বা গ্রাফ কোনও ব্যাপার না) তবে আপনি সেরা পারফরম্যান্স পেতে পারেন। যেহেতু ডাটাবেস ব্যবহারের ক্ষেত্রে বিমূর্ত নয়, তাই ব্যবহার-কেস সর্বাধিক অনুকূল প্রশ্ন / আপডেটগুলি প্রয়োগ করতে পারে এবং এটি যা চায় তা সম্পাদনের জন্য কিছু বিশ্রী অবজেক্ট-মডেলের মধ্য দিয়ে যাওয়ার প্রয়োজন হয় না।
রবার্ট ব্রুটিগাম

ঠিক আছে, মুখ্য লক্ষ্য হ'ল দৃ ,়তার উদ্বেগগুলি ব্যবসায়ের যুক্তি থেকে দূরে রাখা, পরিষ্কার কোড যা বুঝতে সহজ, প্রসারিত এবং পরীক্ষা সহজ to ডিবি প্রযুক্তির অদলবদল করতে সক্ষম হওয়া কেবল একটি বোনাস। আমি দেখতে পাচ্ছি যে দক্ষতা এবং অজ্ঞতার মধ্যে স্পষ্টতই ঘর্ষণ রয়েছে যা আপনি ব্যবহার করতে পারেন এমন শক্তিশালী প্রশ্নের (তবে অনুমতি নেই) এর কারণে গ্রাফ ডিবিতে আরও শক্তিশালী বলে মনে হচ্ছে।
ডাবল এম

1
একটি জাভা এন্টারপ্রাইজ বিকাশকারী হিসাবে আমি আপনাকে বলতে পারি আমরা গত দুই দশক ধরে যুক্তি থেকে দৃ pers়তা আলাদা করার চেষ্টা করেছি। এটি কাজ করে না। প্রথমত, বিচ্ছেদ কখনও সত্যই অর্জন করা যায় নি। আজও, "ব্যবসায়ের" অবজেক্টগুলিতে ডাটাবেস-সংক্রান্ত সমস্ত ধরণের স্টাফ রয়েছে, যার মধ্যে অন্যতম প্রধান ডাটাবেস আইডি (এবং প্রচুর ডাটাবেস টিকা)। দ্বিতীয়ত, যেমনটি আপনি বলেছিলেন, কখনও কখনও ব্যবসায়ের যুক্তি কোনও উপায়ে ডাটাবেসে কার্যকর করা হয়। তৃতীয়ত, সেই কারণেই আমাদের নির্দিষ্ট ডাটাবেস রয়েছে যেখানে ডেটা যেখানে রয়েছে সেখানে কিছু লজিককে সর্বোত্তমভাবে সম্পন্ন করতে সক্ষম হতে হবে।
রবার্ট ব্রুটিগাম
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.