أفضل طريقة للتعامل مع رمز الأعمال المورقة والعرض التقديمي؟

Question

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

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

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

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

هل هذا نهج لائق؟ ما هو الأفضل أن أذهب إلى هذا؟ سوف أرج إلى حكمة الإنترنت الجماعية الخاصة بك.

شكرًا!

Answer 1

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

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

Answer 2

أنا أقترح بتواضع النموذج - View -Controller - MVC لديه احتمال كبير كحل ناجح لمشكلتك. إنه يفصل بين المنطق المختلفة ، كما تصف.

HTH

Answer 3

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

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

ثم كما يقول Justboo ، أعتقد أنه سيكون لديك موقف متميز بما يكفي لبدء استخلاص وحدات التحكم من BL و UI الخاص بك وجعلها تعمل في تصميم MVC.

Answer 4

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

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

رابط واحد آخر من مؤلف من الكتاب.

لذا ، فأنت تكرس ببطء ولكن بثبات إلى الخير الكريمي لـ MVC ، خطوة بخطوة.

HTH