تطوير تطبيق N-Tier.في أي اتجاه؟

Question

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

في أي اتجاه تتحرك؟

• من واجهة المستخدم إلى طبقة الأعمال إلى المستودع إلى قاعدة البيانات؟
• من قاعدة البيانات إلى المستودع إلى طبقة الأعمال إلى واجهة المستخدم؟
• هذا يعتمد.(على ماذا؟)

Answer 1

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

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

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

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

Answer 2

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

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

هتافات.

Answer 3

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

لكن هناك آراء أخرى.

Answer 4

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

بالتفكير في الأمر، ربما تحتاج إلى إجراء بعض التحديثات على جميع الطبقات على أي حال...=)