طبقة رجال الأعمال مع كائنات متعددة مع جميع خصائص شغل من DB أو كائن واحد مع مجموعة فرعية فقط شغل

Question

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

حالة 1

على سبيل المثال, المستخدم ينتمي إلى المدينة التي يتحول ينتمي إلى الدولة والبلد ، User, City, State و Country هل الجداول في قاعدة البيانات الخاصة بي مع الكثير من المجالات ، ولكن أريد قائمة المستخدمين مع قائمة من الأوامر ، لذلك أنا خلق الأعمال كائن يسمى على سبيل المثال UserWithOthers مع الخصائص الهامة (UserId, UserName, CityName, StateName, CountryName, List<Order>) و الدال يسترد إلا أن الحقول من قاعدة البيانات.

الحالة 2

أريد أن أعود الآن مستخدم مع كمية من أوامر لا نهاية مع الحقول التالية في عملي الكائن (UserId, UserName, CityName, StateName, CountryName, OrdersCount) و فئة يمكن أن يسمى على سبيل المثال UserWithOrderCount

لقد فكرت في بعض الخيارات:

1. من فئات الأعمال وملئها بشكل منفصل في كل DAL الطريقة (هذه الكائنات هي بسيطة ولكن النظر في هذا الأسلوب يمكن أن يكون مجمع حدد الاستعلام التي يجب أن تكون مغلفة لإعادة استخدامها حتى نمط مستودع لا تناسب بشكل جيد هنا, على الأقل أعتقد ذلك).
2. إنشاء كائن واحد فقط User مع كل الخصائص (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) وملء مجموعة فرعية فقط في كل DAL الأسلوب ، ولكن هذا يعني الدلالي اقتران عند استخدام الأسلوب ، لأنه يجب أن نعرف أي مجموعة فرعية من الحقول من قاعدة البيانات الدلالية اقتران هو أسوأ من كل اقتران.
3. الخيار 1 لا تعامل بشكل جيد إذا كنت بحاجة إلى وقت لاحق في رأي آخر ، على حد سواء ، List<Order> و OrdersCount خصائص.
4. تنظر الآن أنه إذا كنت تستخدم ASP.NET MVC الممارسات الجيدة يحكي أن كنت في حاجة الى ViewModel لتمرير الرأي ، فكرت في العودة ViewModels من التجاريين طبقة, لكن لا أعتقد أنها فكرة جيدة ، فإنه يشعر وكأنه أنا تنتهك شيئا و هو أيضا غير ممكن لأن طبقة رجال الأعمال في جمعية أخرى وليس تطبيق ويب.
5. أنا لا أريد أن أكتب نفس استعلام Linq مرارا وتكرارا ، ولكن إذا كان استخدام NHibernate أو EFCodeFirst هو "مثل" الخيار الأول و سوف تحتاج إلى إنشاء طن من الأعمال التجارية الصغيرة الكائنات.

كيف يمكنك التعامل مع هذا الوضع ؟ أعتقد أن هذا هو مستوى عال تصميم المقرر.

Answer 1

أولا وقبل كل شيء, أنا بالتأكيد أتفق معك حول بعض الأشياء لا تفعل:

1. لا جزئيا-تعبئة الكائنات الأعمال ، كما يمكنك ثم وضع مسؤولية معرفة الخصائص التي يتم ملؤها على طبقة رجال الأعمال عملاء جدا الممارسة السيئة.

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

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