DTO أو المجال النموذجي الكائن في طبقة العرض?

Question

أعرف أن هذا هو سؤال قديم, ولكن ما هو أفضل من الناحية العملية ؟ باستخدام نموذج المجال كائن في جميع طبقات من التطبيق الخاص بك ، وحتى ملزمة القيم مباشرة لهم على JSP (أنا باستخدام JSF).أو تحويل المجال النموذجي الكائن في DTO في DAO أو خدمة طبقة إرسال خفيفة الوزن DTO إلى طبقة العرض.

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

وأود أن أشير إلى أن بلدي التطبيق يستخدم السبات نموذج الكائنات و يستخدم مخصص إنشاء نموذج الكائنات (يعني لا بد أن أي DB الدورة دائما منفصل).هو أي من السيناريوهات المذكورة أعلاه أكثر فائدة صارمة نموذج كائن نمط ؟ استخدام السبات وقد ضخمة بيتا فيما يتعلق أشياء مثل كسول التهيئة استثناءات.

أنا تحرير هذا السؤال تأمل في تعزيز النقاش (لست متأكدا إذا أنا أفعل هذا من اليمين):

مشكلة لدي مع نموذج الكائنات هو أنها ليست مرنة في كل شيء.التعليق أدناه تقول أن التطبيق يجب أن تكون مصممة بحيث نموذج الكائنات يمكن استخدامها في جميع الطبقات.لماذا ؟ إذا كان المستخدم يريد قطعة من السخرية وظائف من المفترض أن أقول لهم ، 'حسنا هذا لن يعمل مع نموذج الكائنات'?

سهل و بسيط, هناك أوقات عندما نموذج الكائنات لن تعمل.قد يكون لديك:

public class Teacher {
    List<Student> students;
    [tons of other Teacher-related fields]
}
public class Student {
    double gpa;
   [tons of other Student-related fields]
}

ولكن ربما كنت لا تحتاج إلى كل تلك المعلومات.تحتاج فقط المعلم الاسم الأخير ، عدد الطالب يعلمون هذا العام ، ومتوسط المعدل التراكمي لجميع الطلاب جنبا إلى جنب.ماذا ستفعل في هذه الحالة ؟ استرداد كامل المعلومات معلم و طالب العلاقات ومن ثم رمز يحصل على الاعتماد على قائمة الطلاب ، ثم يحسب مجموع متوسط جميع نقاطهم في الداخل ؟ يبدو waaaay جهد أكثر من مجرد خلق DTO مع 'سلسلة اللقب', 'int numStudents" و " ضعف combinedGpa;

قد يبدو مثل رأيي وقد تتكون هذه, ولكن لم تعمل في التطبيق حيث نموذج الكائنات يمكن أن يكون تماما المستخدمة نظيفة في كل حالة.العادية التطبيقات في العالم الحقيقي مع الخروج من المستخدم العادي مطالب فقط لا تعمل بهذه الطريقة.

Answer 1

أنها حقا يتوقف على مدى تعقيد التطبيق الخاص بك.خلط كائنات المجال في عرض طبقة اثنين من الآثار المحتملة:

1. سوف يميل إلى تعديل كائن المجال لاستيعاب الأشياء التي تحتاج إليها في عرض طبقة
2. عرض طبقة تحتوي على تعقيد إضافي بسبب عدم تطابق بين ما نطاقك الكائنات العرض وما وجهة نظركم يحتاج حقا.أنك قد لا تكون قادرة على الحصول على حول هذا التعقيد ولكن ربما لا ينتمي إلى طبقة العرض.

إذا كان المجال الخاص بك كائنات بسيطة و وجهات نظركم قليلة تخطي DTOs قد يكون أبسط شيء.

من ناحية أخرى, إذا كان المجال الخاص بك نموذج من المرجح أن تتطور وتصبح معقدة وإذا وجهات النظر الخاصة بك من المرجح أن تكون عديدة ومتنوعة ، وقد عرض كائنات محددة قد تكون فكرة جيدة.في MVC العالم باستخدام ViewModels هو شائع يجعل الكثير من الشعور بالنسبة لي.

Answer 2

تصويت آخر على كائنات المجال.بقدر المجال يحركها التصميم المعنية نموذج المجال هو ملك وينبغي أن تستخدم حيثما كان ذلك ممكنا.التطبيق يجب أن تكون مصممة بطريقة حيث أن معظم طبقات (شريط طبقة البنية التحتية) يمكن استخدام كائنات المجال.

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

Answer 3

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

لقد جعلت من تجارب جيدة مع عرض نموذج فقط يلتف حول كائنات المجال و المندوبين معظم العمليات لهم.هذا فصل عرض النطاق طبقة تسمح مرونة تكوين كائنات المجال و لا يزال ليس هناك الكثير من العمل لتنفيذ منذ ايديس دعم وفد نمط.

Answer 4

سيناريوهات عندما كائن المجال هي إشكالية ليتم إرسالها :

1. قد تحتاج إلى معلومات مجمعة أو أنواع أخرى من الحقول المحسوبة' أرسلت إلى طبقة واجهة المستخدم ( في المثال فليكس / GWT ) و لا تريد أن تعبث كائن المجال
2. قد تواجه الحاجة إلى التسلسلية دوري كائن الرسم البياني ( في سبيل المثال ، إذا كان الطالب قائمة علاقة ) , بعض البروتوكولات يكون لديك مشاكل مع هذا
3. السبات LazyInitializationException عند التعامل مع إطار serializers ( blazeDS المرن / GWT مسلسل)

أنا لست متأكدا من أنها واضحة المعالم الجواب في تلك cirumcstances

Answer 5

في رأيي ليس هناك مشكلة على الإطلاق مع استخدام نموذج المجال الكائنات في كل طبقة.أنت قلت أنك لا تحتاج إلى كل المعلومات.عندما كنت في وحدات jsp, فقط استخدام البيانات التي تحتاج إليها.لا أحد يجبرك على جلب كل مكان الإقامة.قلت أيضا أن تحتاج إلى إجراء الحسابات المتعلقة خصائص الكائن من أجل الحصول على المعدل التراكمي, # من الطلاب ، إلخ.لديك 3 خيارات:إنشاء الاصطناعية خصائص في المجال الخاص بك نموذج كائن إرجاع البيانات المناسبة لك ملفوفة جميل وأنيق.هل الحسابات في أي تحكم أو خدمة طبقة تعرض لها خلال المناسبة حاصل;أو التعامل مع كل شيء داخل JSP.أنت بحاجة إلى استرداد/ترجمة/انتزاع البيانات على أي حال فلم إضافة مزيد من التعقيد مع DTO.

بالإضافة إلى ذلك, مع كل DTO أنت خلق.) فئة إضافية لديك الآن للحفاظ على ، ب.) على الأقل 1 إضافية الأسلوب في مكان ما في بعض الفئة التي يبني و بملء DTO (DAO, طريقة مصنع ، إلخ.).المزيد من الصيانة = التعيس المطور 6 أشهر في وقت لاحق.

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

Answer 6

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

المجال يجب أن تكون مغلفة ومحمية من تعديل من قبل شخص لا يهتم بصحة المجال.

تسريب السلوك لا أفضل عادة.

إذا كان مشروع صغير, بنيت مع الصحيح principes كذلك.هكذا نحن دائما نضع في اعتبارنا لماذا نفعل ما نفعل ، ليس فقط كيف.

Answer 7

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

من ناحية أخرى أعتقد أن هناك عدد قليل جدا من الأشياء التي عموما لا ينبغي القيام به.أولئك الذين يقولون كل DTOs هي الشر خطأ - أنه يعتمد دائما على استخدام حال!هل هم حقا له ما يبرره ؟

و أخيرا أنا شخصيا أعتقد كائنات المجال يجب أن تدعنا نذهب إلى عرض نفسها.تخيل ما النصيبه التكامل ثم مثل.ولكن تأخذ الربيع MVC على سبيل المثال - المجال ستبقى ثم في طبقة التطبيق ربما...

Answer 8

DTO يعتبر على نطاق واسع مضاد نمط في الوقت الحاضر, و النصيحة هي عادة "تجنب لهم في جميع التكاليف".

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