সত্তা ফ্রেমওয়ার্ক সহ ডোমেন চালিত ডিজাইনের সমস্যাগুলি

Question

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

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

আমি যদি মতামত ভিত্তিক প্রশ্ন জিজ্ঞাসা করি তবে আমি মারাত্মক ক্ষমা চাইছি, তবে ...

যখন অনুশীলনের কথা আসে - সত্তা ফ্রেমওয়ার্ক সর্বাধিক শক্তিশালী এবং বহুল ব্যবহৃত ওআরএম। দুর্ভাগ্যক্রমে আপনি এর সাথে ডিডিডি কভার করার একটি বিস্তৃত কোর্স পাবেন না।

---

গুরুত্বপূর্ণ দিক:

• সত্তা ফ্রেমওয়ার্ক DbSetবাক্সের বাইরে ইউওডাব্লু এবং সংগ্রহশালা ( ) আনায় brings

• EF এর সাথে আপনার মডেলগুলির নেভিগেশন বৈশিষ্ট্য রয়েছে

• মতিন সঙ্গে মডেলের সব সবসময় প্রাপ্তিসাধ্য বন্ধ DbContext(তারা একটি হিসাবে প্রতিনিধিত্ব করা হয় DbSet)

pitfalls:

• আপনার গ্যারান্টি দিতে পারবেন না যে আপনার শিশুদের মডেলগুলি কেবলমাত্র সামগ্রিক রুটের মাধ্যমে প্রভাবিত হবে - আপনার মডেলগুলির নেভিগেশন বৈশিষ্ট্য রয়েছে এবং সেগুলি সংশোধন করে কল করা সম্ভবdbContext.SaveChanges()

• সঙ্গে DbContextআপনি আপনার প্রতি মডেল অ্যাক্সেস করতে পারেন, এইভাবে circumventing মোট রুট

• আপনি মাধ্যমে রুট বস্তুর সন্তান অ্যাক্সেস সীমাবদ্ধ করতে পারে ModelBuilderমধ্যে OnModelCreatingপদ্ধতি তাদের ক্ষেত্র হিসেবে চিহ্নিত করে এখনও আমি এটা DDD সম্পর্কে যেতে ডান উপায় বিশ্বাস করে না তাছাড়াও এটি এডভেন্ঞার ট্যুরিজম কি ধরনের এই ভবিষ্যতে হতে পারে নির্ণয় করা কঠিন (- বেশ সন্দিহান )

বিবাদ:

• সংগ্রহস্থলের অন্য স্তরটি প্রয়োগ না করে যা সমষ্টিগতভাবে ফিরে আসে আমরা উপরোক্ত উল্লিখিত সমস্যাগুলিও আংশিকভাবে সমাধান করতে পারি না

• সংগ্রহস্থলের অতিরিক্ত স্তর প্রয়োগ করে আমরা EF এর অন্তর্নির্মিত বৈশিষ্ট্যগুলি উপেক্ষা করছি (প্রত্যেকটি DbSetইতিমধ্যে একটি রেপো) এবং অ্যাপটিকে অতিরিক্ত জটিল করে তুলছি

---

আমার উপসংহার:

দয়া করে আমার অজ্ঞতা ক্ষমা করুন, তবে উপরের তথ্যের উপর ভিত্তি করে - এটি হয় ডোমেন-চালিত ডিজাইনের জন্য সত্তা ফ্রেমওয়ার্ক পর্যাপ্ত নয় বা ডোমেন-চালিত ডিজাইন একটি অসম্পূর্ণ এবং অপ্রচলিত পদ্ধতি is

আমি সন্দেহ করি যে প্রতিটি পদ্ধতিরই এর গুণাবলী রয়েছে তবে আমি এখন সম্পূর্ণ হারিয়েছি এবং কীভাবে ডিডিডি দিয়ে ইএফের সাথে মিলিত করতে হবে তার সামান্যতম ধারণা নেই।

---

যদি আমি ভুল হয় - কেউ কি EF- এর সাথে ডিডিডি সম্পর্কে কীভাবে যেতে পারেন তার একটি সহজ নির্দেশাবলী (বা এমনকি শালীন কোড উদাহরণ প্রদানও) করতে পারে?

Comments

আমি কীভাবে EF কাজ করে তা বোঝার জন্য আমি এখানে পদক্ষেপগুলি বিশদভাবে জানলাম । তবুও এই পদক্ষেপগুলি নাভির মাধ্যমে বাচ্চাদের অ্যাক্সেস করার সমস্যাটি পরিচালনা করে না। বৈশিষ্ট্য বা ডিবিসেটস দ্বারা ডিবি কনটেক্সট বন্ধ।

— অ্যালেক্স হারমান

Answer 1

একে অপরের সাথে ডিডিডি এবং ইএফের তেমন কিছু করার নেই।

ডিডিডি একটি মডেলিং ধারণা। এর অর্থ ডোমেন, ব্যবসায়ের প্রয়োজনীয়তা এবং সেগুলির মডেল সম্পর্কে চিন্তা করা। বিশেষত অবজেক্ট-ওরিয়েন্টেশনের প্রসঙ্গে এর অর্থ এমন একটি নকশা তৈরি করা যা ব্যবসায়ের কার্যকারিতা এবং সক্ষমতা আয়না করে।

EF একটি অধ্যবসায় প্রযুক্তি। এটি মূলত ডেটা এবং ডাটাবেস রেকর্ডের সাথে সম্পর্কিত।

এই দু'জনের তীব্রভাবে তালাক হয়। একটি ডিডিডি ডিজাইন হুডের অধীনে কিছু ফর্ম EF ব্যবহার করতে পারে, তবে দু'জনকে অন্য কোনও উপায়ে যোগাযোগ করা উচিত নয়।

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

এই ব্যাখ্যাটি ত্রুটিযুক্ত, এবং আমি দৃ strongly়ভাবে এটি উপেক্ষা করার পরামর্শ দেব।

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

Comments

EF কেবলমাত্র একটি সময় রক্ষাকারী। সামগ্রিক পরিবর্তন-ট্র্যাকিং এবং অধ্যবসায় যেখানে ইএফ ইতিমধ্যে অনেক সহায়তা করে। দুর্ভাগ্যক্রমে, বর্তমানে কনফিগারেশন স্তরে সমষ্টিগুলির আকৃতি নির্ধারণ করার কোনও উপায় নেই।

— পাভেল ভোরোনিন

Answer 2

EF এর জন্য এটি ব্যবহার করুন যেমন ডেটা অ্যাক্সেস লাইব্রেরি যা কাঁচা ADO.NET এর চেয়ে সামান্য বেশি শক্তভাবে টাইপ করা হয়। আমি কাঁচা ডেটাসেট বা ডেটা টেবিল ব্যবহার করে ডোমেন মডেল করার পরামর্শ দিই না তেমনই আমি ই এম সত্তা ক্লাস ব্যবহার করে আপনার ডোমেনকে মডেল করার পরামর্শ দেব না।

আমি বুঝতে পারি যে EF ডাটাবেস অ্যাক্সেস এবং ডোমেন মডেলিংয়ের মধ্যে একটি শর্টকাট হিসাবে বিক্রি হচ্ছে তবে এই পদ্ধতির অভ্যন্তরীণভাবে ত্রুটিযুক্ত কারণ এটি দুটি মূলত সম্পর্কহীন সমস্যার সমাধান করে। .NET- এ আরও কিছু প্রচেষ্টা ছিল যাতে কোনও শ্রেণি সম্পূর্ণরূপে অসম্পৃক্ত জিনিসগুলি (যেমন। নেট রিমোটিং) সম্পাদন করে এবং সেগুলি ভালভাবে শেষ হয় নি।

পোকো ক্লাস ব্যবহার করে ডিডিডি করুন এবং আপনার ডিজাইনটি ড্রাইভ করতে ডাটাবেস স্কিমাটি দেবেন না। EF- র সংগ্রহস্থল / অধ্যবসায় স্তরের ভিতরে রাখুন এবং EF সত্তাগুলি বাইরে ফুটো হতে দেবেন না।

Answer 3

সত্তা ফ্রেমওয়ার্ক বাক্সের বাইরে ইউওডাব্লু এবং সংগ্রহশালা (ডিবিসেট) এনেছে

না।

সত্তা ফ্রেমওয়ার্ক বিমূর্তিগুলি ডিডিডি নয়, ওআরএম দিয়ে তৈরি করা হয়েছিল। DbSetসত্তা কাঠামোর কোনো সংস্করণে বিমূর্ততা একটি DDD সংগ্রহস্থলের প্রয়োগ সরলতা কাছাকাছি কোথাও না হয় - উল্লেখ না DbContextযা একটি অপরিমেয় জিনিষ একটি UnitOfWork চেয়ে বেশি অনাবৃত।

EF কোর ২.১ এর বিমূর্তের উপাদানগুলির একটি অ-বিস্তৃত তালিকা এখানে রয়েছে DbSet<TEntity>যা আমাদের ডিডিডিতে দরকার নেই:

• Attach(TEntity) এবং তার সমস্ত ভাইবোন
• Find(Object[])
• Update(TEntity) এবং তার সমস্ত ভাইবোন
• বাস্তবায়নকারী IQueryable

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

নীচের লাইন: আপনাকে অবশ্যই এই চর্বিগুলি সুন্দর, প্রবাহিত ধারণাগুলিতে আবদ্ধ করতে হবে এবং অনুমান করতে হবে যে, এর অর্থ অতিরিক্ত ক্লাস চালু করা।

আপনি ইএফ এবং ডিডিডি দিয়ে কী করতে পারেন তার অপেক্ষাকৃত দৃ sound় উদাহরণ (যদিও প্রকাশিত কিছু দৃষ্টিভঙ্গি বিতর্কযোগ্য): https://kalele.io/blog-posts/modeling-aggregates-with-ddd-and-entity-framework/

অন্যরা স্থিরভাবে অতিরিক্ত স্তর উত্পন্ন করছে, প্রায়শই সমষ্টিগত শিকড়গুলিতে DbContext ইনজেকশন দিয়ে এসআরপি লঙ্ঘন করে

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

যদিও এটি কোনও বৈধ পন্থা হতে পারে যদি এটি কোনও শিক্ষিত ট্রেড অফ ছিল তবে সাম্প্রতিক অ্যান্টি-রিপোজিটরি, "সত্তা ফ্রেমওয়ার্ক মিনিমালিজম" প্রবণতা বিভ্রান্তিকর। এটি হ'ল ডিডিডি নিদর্শনগুলিকে দোষারোপ করে যা সত্তা ফ্রেমওয়ার্কের সাথে ঘটে যখন এটি সত্যই EF নির্মাতারা হয় যা তাদের কাঠামোটিকে বাক্সের বাইরে সেরা অনুশীলনের সাথে সামঞ্জস্য করার জন্য কিছুই করেনি। কোড সুরক্ষা এবং রক্ষণাবেক্ষণের ক্ষেত্রে যে সমস্ত সমস্যা তৈরি হতে পারে তার সাথে তারা সমস্ত কাঠামোর সাথে দৃly়ভাবে মিলিত হচ্ছে All

Answer 4

বিবাদ:

সংগ্রহস্থলের অন্য স্তরটি প্রয়োগ না করে যা সমষ্টিগতকে ফেরত দেয় আমরা এমনকি> আংশিকভাবে উপরে বর্ণিত সমস্যাগুলি সমাধান করতে পারি না

সংগ্রহস্থলের অতিরিক্ত স্তর প্রয়োগ করে আমরা EF এর অন্তর্নির্মিত বৈশিষ্ট্যগুলি উপেক্ষা করছি (প্রতিটি ডিবিসেট ইতিমধ্যে একটি রেপো) এবং অ্যাপ্লিকেশনটিকে অতিরিক্ত জটিল করে তুলছে

আমি একটি অ্যাপ্রোচ ব্যবহার করেছি যেখানে প্রতিটি সমষ্টি তার নিজস্ব ডিবিসিঙ্কটেক্সট পায়, সমষ্টিগুলির জন্য প্রয়োজনীয় যা ঠিক তা ম্যাপিং করে। আমি মনে করি এটি জুলি লারম্যানও বর্ণনা করেছেন।

এটি খুব ভালভাবে কাজ করেছে, তবে এটি আরও আকর্ষণীয় মডেলগুলির পক্ষে যথেষ্ট নয়, যেখানে আপনি নিজের ধারণাগুলিকে আপনার সত্ত্বার সাথে সংযুক্ত করতে চান না।

Comments

এই ভিডিওটিও

— অ্যালেক্স হারম্যান

DBContext per Agregregate পদ্ধতির কোনও সুবিধা আছে কি? এটি কি ইএফ দিয়ে ডিডিডি বাস্তবায়নের ডিফল্ট উপায়?

— অ্যালেক্স হারমান

জুলি লারম্যানের বাউন্ডেড প্রসঙ্গে প্রতি ডিবি কনটেক্সট মানে না?

— এমভিশন

Answer 5

বিবেচনার জন্য কেবল সম্ভাব্য সমাধানটি ভাগ করে নিতে চাই:

1. সরাসরি সার্ভিস লেয়ারে ইএফ প্রকল্পটি রেফারেন্স এড়ান

2. অতিরিক্ত সংগ্রহস্থল স্তর তৈরি করুন (ইএফ প্রকল্প ব্যবহার করে এবং সমষ্টিগত রুট প্রদান করে)

3. পরিষেবা স্তর প্রকল্পে সংগ্রহস্থল স্তর উল্লেখ করুন

আর্কিটেকচার :

• UI 'তে

• নিয়ামক স্তর

• পরিষেবা স্তর

• সংগ্রহস্থল স্তর

• সত্তা ফ্রেমওয়ার্ক

• মূল প্রকল্প (ইএফ মডেলগুলি ধারণ করে)

---

এই পদ্ধতির সাথে আমি যে দোষগুলি দেখছি:

• যদি কোনও সংগ্রহস্থল সমষ্টিগত রুটটিকে EF মডেল ট্রি হিসাবে না ফেরৎ দেয় (উদাহরণস্বরূপ আমরা কোনও ম্যাপযুক্ত বস্তুটি ফিরিয়ে দিই) - আমরা পরিবর্তনগুলির ট্র্যাকিংয়ের EF এর ক্ষমতা হারাচ্ছি

• যদি সমষ্টিগত রুট একটি EF মডেল হয় - এর সাথে নেভিগেশন করতে না পারলেও এর সমস্ত নেভিগেশন বৈশিষ্ট্য এখনও উপলব্ধDbContext ((আমরা পরিষেবা স্তরটিতে ইএফ প্রকল্পের উল্লেখ করি না)