الخلط بين DTOs (linq2sql) و فئة الأشياء!

Question

لقد تم العمل بنجاح مع linq2sql و linq DTOs (الطبقات التي يتم إنشاؤها بواسطة linq2sql) ....

أنا في حيرة, لدي مهمة تحديث قديم تطبيق أنني DTOs سيتم استخدامها وكيف ينبغي أن تكون ....لنقل التاريخ

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

هذه الطبقة الكائنات basicaly صورة طبق الأصل (أكثر أو أقل) من dtos - هناك بعض التغييرات في بعض مكان ولكن عموما نفس..

وبالعودة إلى مسألة في متناول اليد!-- هذا هو ممارسة جيدة استخدام dtos فقط لنقل البيانات من مستودع إلى طبقة الخدمة ...ومرة في خدمة طبقة(منطق الأعمال) ولكن ينبغي لي أن رسم كل dtos أن هناك كائن فئة أجزاء العداد (طبعا باستخدام automapper!!)

بلدي البديل الآخر هو الاستمرار في استخدام DTOS مثل كائنات فئة وتمريرها حول من أسلوب إلى أسلوب و العودة أنواع الخ ولكن أشعر بأن هذا هو ممارسة سيئة وأظل أدور في دوائر أتساءل الطريقة التي يجب أن تطبق ؟

أي مساعدة أقدر

شكرا

Answer 1

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

[هذه الدرجة الكائنات basicaly مرآة الصورة]...

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

حتى هنا هو بلدي الحل:
أنا "برمجة واجهة".

دعونا نقول لدي PersonDto (Dto الدائمة لنقل البيانات كائن) مع خصائص FirstName, LastName, Age (التي تتصل مباشرة إلى قاعدة بيانات الأعمدة).

أنا خلقت IPerson واجهة لها PersonDto تنفيذ ذلك.

  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

و مستودع طريقة تأخذ في استرداد IPerson بدلا من Linq2Sql الدرجة.

    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

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

بعض المؤشرات العامة:بناء الخاصة بك DTO ما باليد...وأنا أعلم أنه يبدو جنونا لكن ستجد أنه يعمل بشكل جيد مع أعلى إلى أسفل ، اختبار مدفوعة نهج التنمية.الخاص بك DTO هو (linq2Sql) الكائنات سوف تكون خفيفة للغاية و سوف تكون مفتوحة التغييرات خارج .dbml مصمم.

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

وضع كل طبقة الوصول إلى البيانات في مشروع منفصل (مرة أخرى لتطبيق هذا الفصل).

وضع واجهة الإعلانات في مشروع منفصل (وهذا يضمن أنك لا تصل إلى أي المراجع الدائرية).

ويساعد هذا الأمل...

Answer 2

في الحقيقة لدي سؤال مماثل حول هذا الموضوع على الرغم من أن نيتي كانت مختلفة قليلا.التوصية هو استخدام Linq2SQL الطبقات كائنات المجال والاستفادة من فئات جزئية كما ذكر آخرون.قلقي الرئيسي جاء مع شكل هذه الكائنات (أي الأسماء الملكية) ، والوصول إلى أعضاء الفئة (أي خاصة v. s.المحمية على سبيل المثال).

شكل الكائنات وحتى الوصول يمكن معالجتها باستخدام قوالب t4 حيث داميان الحرس وضعت T4 قالب يسمح لك التحكم في شكل فئات Linq2Sql سوف تولد لك.هذا يمكن أن ينظر إليه هنا T4 قالب Linq2SQL.

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

ويساعد هذا الأمل.

Answer 3

هذا هو واحد من أفضل مناقشات الموضوع الذي رأيت:

http://blog.wekeroad.com/blog/linqtosql-momma-said-knock-you-out/

في النهاية, اقتران والتماسك القرارات الظرفية وعليك أن تقرر ما هو أفضل من أجل الوضع الخاص بك.

عند التطبيق الخاص بك ينمو LinqToSql كيف سيكون من السهل أن أنزع LinqToSql وإدراج أخرى ORM في هذا المكان ؟ هذا هو شيء لديك للتفكير جديا.

في العام ، والتقليل من المعرفة عملك طبقة عن LinqToSql.LinqToSql ينبغي أن تكون مخفية تماما من طبقة واجهة المستخدم الخاصة بك (الأعمال التجارية الخاصة بك طبقة تشكل جزءا كبيرا من هذا الدرع).فإنه من السهل جدا أن تذهب الخطأ المعمارية المسار مع LinqToSql وأنه يمكن أن يكون من الصعب جدا الحصول مرة أخرى على الطريق الصحيح بعد وقوعها.

Answer 4

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