يجب أن تستمد Pocos من DTOS أو أفضل لا؟

Question

عند إنشاء محلول N-Tier، لا أريد أن أعرض كائنات عملي، لكن استخدام DTO بدلا من ذلك. على الجانب الآخر، لا أرغب في تحديد الكائنات مضاعفة وكتابة رمز النسخ طوال الوقت.

الآن ستكون فكرتي هي كتابة DTOS التي تحتوي على جميع الحقول والخصائص الضرورية، ولكن لا توجد منطق (حالة فقط).

ثم سأشتقيم كائنات عملي من تلك DTOS، وتمديدها مع منطق عملي، والعمل على خصائص فصول قاعدة DTO. هذه الكائنات ستكون أيضا الكائنات المستمرة في orm المستخدمة (nhibernate).

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

هل تعتقد أن هذا النهج معقول؟

يعتبر،

سيباستيان

Answer 1

قد ترغب في مراعاة ما يلي:

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

أفضل حل هو استخدام نمط المجمع, ، والتي تخلق DTOS من كائنات الأعمال والعكس صحيح. المجمع هو مثال متخصص mapper. نمط المذكورة أيضا في أنماط تطبيقات تطبيق المؤسسة...."

من نمط وممارسة: كائن نقل البيانات

أيضا، لم أستخدمها بنفسي، لكنك قد ترغب في تسجيل المغادرة Automapper. كذلك.

Answer 2

يبدو معقولا بالنسبة لي. في LinQ إلى SQL، يتم اشتقاد كائنات الأعمال من DTO باستخدام الفصول الجزئية.

Answer 3

"ثم استشأت كائنات العمل الخاصة بي من هؤلاء DTOS" ضع في اعتبارك أن DTOS قد تبدو مختلفة عن Bo قد تحتوي على خصائص من 2 أو 3 بو