MVC لتطبيق سطح المكتب مع عدم وجود طبقة بيانات

Question

قد يكون السؤال صعبا (بسبب طبيعته أو طريقي لوصفه)، لذلك قرأ هذا حقا قبل الإجابة.

لدي هذا التطبيق لكتابة:
أ) تطبيق سطح المكتب؛
ب) لا طبقة بيانات بمعنى قاعدة البيانات أو الملفات أو أي مستودع آخر (لا حاجة لحفظ أو تخزين أو تحميل البيانات)؛
ج) سيكون لدى التطبيق بعض خوارزميات الحسابات المنفذة (الخوارزمية الوراثية)؛
ب) يوفر واجهة المستخدم الرسومية التي ستعرض أدوات التحكم في التطبيقات والحسابات.

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

1. واجهة المستخدم الرسومية هي الرأي. geneticalgorithm هو وحدة تحكم. geneticalgorithmresults هو النموذج (كصف يخزن البيانات فقط). التدفق الأساسي:

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

2. واجهة المستخدم الرسومية هي الرأي. AppEngine هو وحدة تحكم. geneticalgorithm nad geneticalgorithmresults هي النموذج. الآن لدينا:

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

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

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

ما النهج الذي تنصح به؟ أو ربما يجب علي مزجها واستخدم العمارة النهج الأول مع تدفق الاتصالات من النهج الثاني؟ أو بعض التصميم المختلفة؟

Answer 1

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

في رأيي، مزيج من كلاهما فكرة جيدة. إذا انتهى بعض المنطق في النموذج، فليس هذا هو نهاية العالم، فهذا يعني أن عليك أن تكون أكثر حذرا بشأن تتبع فصل مكوناتك. إذا كان التعديل الصغير إلى MVC يجعل حياتك أسهل بنسبة 50٪ (أقل برسالة واحدة)، فمن المحتمل أن تكون فكرة جيدة.

Answer 2

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

النظر في: أين هو المنطق للتعامل مع المهام الدنيوية مثل التبديل بين الخوارزميات، وتنفيذها ومعالجة البيانات للعرض؟

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

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

ستشهد طبقة العمل Isolerver التي تأخذ المدخلات، وسوف تتصل mySolver.Solve (). يجب أن تكون قادرا على التبديل بين الإصدارات المختلفة دون الحاجة إلى تغيير منطق طبقة عملك (فتح مبدأ مغلق). يجب أن يكون الفرق الوحيد في الطريقة التي يجب أن يتفاعل منطق العمل مع الخوارزميات في المنشئ، وحتى هناك، يجب عليك التفكير في استخدام نمط المصنع.