التصميم المعتمد على المجال مقابل التصميم المعتمد على قاعدة البيانات لتطبيق ويب MVC

Question

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

المشروع الجديد له هدفين رئيسيين

• القابلية للتوسعة (لمتطلبات خطوط الأنابيب الحالية والمستقبلية)
• أداء

أنوي إنشاء المشروع الجديد ليحل محل التصميم المعتمد على قاعدة البيانات (DBDD) مع التصميم المعتمد على المجال (DDD) مع مراعاة متطلبات التوسعة.ومع ذلك، يبدو أن الانتقال من التصميم المعتمد على قاعدة البيانات إلى التصميم المعتمد على المجال يؤثر عكسيًا على متطلبات الأداء إذا قارنته بأداء تطبيق DBDD القديم.في التطبيق القديم، فإن أي استدعاء للبيانات من واجهة المستخدم سوف يتفاعل مباشرة مع قاعدة البيانات وسيتم إرجاع أي بيانات في شكل DataReader أو (في بعض الحالات) DataSet.

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

أو هل هناك طريقة في DDD لتحقيق كليهما، القابلية للتوسعة التي يوفرها DDD والأداء الذي يوفره DBDD؟

Answer 1

هل فكرت في شكل ما من أشكال فصل استعلام الأوامر حيث تكون التحديثات من خلال نموذج المجال ولكن تأتي القراءات كقارئي بيانات؟DDD الكامل ليس مناسبًا دائمًا.

Answer 2

"الآن مع وجود DDD صارم، سيتم توجيه أي استدعاء للبيانات عبر طبقة الأعمال وطبقة الوصول إلى البيانات."

لا أعتقد أن هذا صحيح، وهو بالتأكيد غير عملي.أعتقد أن هذا يجب أن يقرأ:

الآن مع تطبيق DDD الصارم، يمكن لأي دعوة للحصول على عملية سيتم توجيهها من خلال طبقة الأعمال وطبقة الوصول إلى البيانات.

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

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

وكما ذكر Chriseyre2000، يهدف CQRS إلى حل هذه المشكلات بالتحديد.

Answer 3

لا ينبغي أن يكون لاستخدام DDD آثار كبيرة على الأداء في السيناريو الخاص بك.ما يقلقك يبدو أشبه بمشكلة الوصول إلى البيانات.يمكنك الرجوع إليها باسم

تهيئة كائن الأعمال وكائن الوصول إلى البيانات

لماذا تعتبر "التهيئة" باهظة الثمن؟ما هي آليات الوصول إلى البيانات التي تستخدمها؟

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

على أية حال، يحتاج NHibernate فقط إلى التهيئة مرة واحدة عند بدء تشغيل التطبيق، وبعد ذلك يستخدم نفس تجمع اتصال ADO.NET مثل برامج قراءة البيانات العادية.لذلك يتلخص الأمر كله في رسم الخرائط المناسبة واستراتيجية الجلب وتجنب الأخطاء التقليدية في الوصول إلى البيانات مثل "تحديدات n+1".