نمط تحميل الكيان التجاري

Question

المشروع الذي أعمل عليه يستخدم بنية n-tier.طبقاتنا هي كما يلي:

• الدخول الى البيانات
• منطق الأعمال
• هيئات تجارية
• عرض تقديمي

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

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

يتم إنشاء جميع طبقاتك (بما في ذلك قاعدة البيانات) من قاعدة بيانات تعريفية داخلية نستخدمها لتشغيل منشئ التعليمات البرمجية محليًا.

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

أنا متأكد من أن هناك نوعًا من الطقطقة القياسية للقيام بذلك.أي اقتراحات؟

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

Answer 1

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

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

يحرر:معلومات إضافية

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

أتمنى أن يساعدك هذا.

Answer 2

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

public class Relation<T>
{
  private T _value;

  private void FetchData()
  {
    if( LoadData != null ) {
      LoadDataEventArgs args = new LoadDataEventArgs(typeof(T), /* magic to get correct object */);
      LoadData(this, args);
      _value = (T)args.Value;
    }
  }

  public event EventHandler<LoadDataEventArgs> LoadData;

  public T Value {
    get {
      if( _value == default(T) )
        FetchData();
      return _value; 
    }
    set { /* Do magic here. */ }
  }
}

ثم تعلن ذلك على كيانك مثل:

[RelationCriteria("ID", EqualsMyProperty="AddressID")]
public Relation<Address> Address {
  get; set;
}

والأمر متروك للمحمل من النوع الذي يعلن عن خاصية العنوان لإضافة معالج إلى حدث LoadData.

تطبق فئة مماثلة IList لتمنحك علاقة رأس بأطراف.

Answer 3

اي لغة تستخدم؟ما وصفته هو بالضبط ما يفعله Entity Framework في .Net.لكنك لم تشارك اللغة التي كنت تستخدمها وأفترض أنك لا تريد إعادة كتابة أي من طبقة البيانات الخاصة بك.