مفاهيم DDD في تطوير الطبقة n

Question

بعد قضاء شهرين في دراسة منهجية DDD ، بدأت الآن في تطبيق هذه المفاهيم على منتجات فعلية في شركتي. في الواقع ، لقد تم تكليفها بإنشاء بنية مناسبة ويمكن صيانتها للتنمية المستقبلية.

لقد قررنا الاستفادة من التقنيات التالية: EF4 (V2 حقًا) ، الوحدة

كمية المعلومات التي حصلت عليها كانت أكثر تنويرًا ، ومع ذلك ، فقد تركت عدة أسئلة في أفضل الممارسات:

السؤال رقم 1: DTOs - أفضل الممارسات

لدي كائنات النطاق الخاصة بي (فئات POCO). هناك عدة طرق لتنفيذ هذه الفئات.

1. النهج التقليدي: قم بإنشاء فصول POCO التي تحتوي على getters/المستقلين العامة ، والتحقق من الصحة ، ومنطق العمل المناسب. قم أيضًا بإنشاء DTOs واستخدم تقنيات التعيين لإدارتها. (السيارات)
2. التقليدية - DTO: إنشاء فئات POCO كما هو مذكور أعلاه ، ومع ذلك ، استخدم POCOS ككائنات نقل. أفهم أن الأشياء التجارية يجب ألا تترك المجال أبدًا.
3. الهجين: لقد تعثرت على مثيرة للاهتمام مشاركة مدونة حيث يقوم المؤلف بإنشاء كائناته POCO و DTOs. داخل كائن المجال الخاص به ، يخلق مثيلًا لـ DTO. هذا يسمح بسهولة الصيانة لأنك لا تكرر خصائصك كما في #1. مثل ذلك:

public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{

 public T Data { get; set; }

 public POCOBase()
 {
     Data = new T();
 }

 public POCOBase(T dto)
 {
     Data = dto;
 }
  }

  public class SomePOCO : POCOBase { }

  public class SomeDTO : DTOBase

  {

 public String Name { get; set; }

 public String Description { get; set; }

 public Boolean IsEnabled { get; set; }
}


// EXAMPLES
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// return somePOCO.Data;

السؤال 2: ما هي الأشياء التي يجب إرجاعها بواسطة طبقة واجهة المستخدم/الخدمة؟

هذا هو الهدف الكامل من DTO. كائن بسيط للغاية وخفيف الوزن يحتوي على سمات عارية فقط. كما أنه لا يحتوي على أي نتائج التحقق من الصحة. إذا قمت بتسلسل DTOs إلى العميل ، فيجب افتراض أن العميل يحتاج إلى أي نتائج التحقق من الصحة مثل مجموعة غير صالحة.

على سبيل المثال ، قل أنني أعمل مع API من Amazon. أود إضافة كتاب إلى متجري الشخصي. إذا حاولت إضافة كتاب دون إرسال ISBN الخاص به ، فمن المحتمل أن تُرجع الخدمة نوعًا من مجموعة الاستجابة التي تحتوي على أخطاء نتيجة التحقق.

هل فاتني شيء؟ كنت تحت الانطباع (على الأقل من DDD "purists") أن DTOs يجب أن لا تحتوي على منطق عمل. يبدو لي أن DTOs لا توفر معلومات كافية ككائنات نقل. إما ذلك أو أحتاج إلى نوع جديد من كائن الاستجابة الذي يلف نتائج DTO والتحقق من الصحة.

السؤال 3: كم IOC أكثر من اللازم؟

يبدو لي من الواضح أنني يجب أن أتبع القاعدة الذهبية:

"حدد أجزاء التطبيق التي تختلف ، وانفصال عن تلك التي تبقى كما هي."

بالنسبة لي هذا أمر منطقي من حيث تطبيق IOC. لتقليل التبعيات ، تتواصل جميع عروض العرض ، ومنطق العمل ، وطبقات الوصول إلى البيانات عبر حاوية IOC. تحتوي طبقة التطبيق الخاصة بي على واجهات وتجريدات مشتركة. يبدو من المفرط استخدام IOC أكثر من هذا بكثير. أحب حقيقة أنه يمكنني إنشاء مستودعات اختبار وهمية - وببساطة تغيير تكوين الوحدة ، يمكنني الاستفادة من TDD.

آمل أن أكون قد ذكرت هذه الأسئلة بوضوح. شكرا لمساعدتكم مقدما!

Answer 1

سأحاول معالجة أسئلتك واحدة تلو الأخرى.

الإجابة 1

DTOs متعامد مع DDD لأنها تخدم غرض مختلف في مكان مختلف في بنية التطبيق. ومع ذلك ، فإن DTOs ليس لها مكان في نموذج المجال لأنهم ليس لديهم سلوك وبالتالي سيؤدي إلى ذلك نماذج مجال فقر الدم.

Pocos مع الجهل الثابت هو الطريق للذهاب. جيريمي ميلر لديه جيد مقال يشرح هذا المفهوم.

الإجابة 2

غالبًا ما تحتاج الطبقات التي تجلس فوق نموذج المجال إلى إعادة كائناتها المصممة خصيصًا لهذا الغرض المعني.

بالنسبة إلى UIS ، يعمل نمط MVVM بشكل جيد بشكل خاص. هذه المقالة يقدم MVVM لـ WPF ، ولكن النمط يعمل أيضًا مثل السحر في ASP.NET MVC.

بالنسبة لخدمات الويب ، هذا هو المكان الذي ينطبق فيه نمط DTO. عقود بيانات WCF هي DTOs ، في حال كنت تتساءل :)

سيتطلب ذلك الكثير من الخرائط ذهابًا وإيابًا بين واجهة الخدمة ونموذج المجال ، ولكن هذا هو السعر الذي يجب أن تدفعه مقابل التصميم المرن. قد تجد السيارات مفيد في هذا الصدد.

الجواب 3

كلما زادت IOC (حقًا: di) ، كان الأمر أفضل ، ولكن شيء واحد في سؤالك أدهشني: يجب أن تقوم حاوية DI بتسليم الرسم البياني للكائن فقط ثم الخروج من الطريق. يجب ألا تعتمد الكائنات على حاوية DI.

نرى هذا حتى الإجابة لمزيد من التفاصيل.