أين هي قواعد العمل في MVC

Question

الآن بعد أن يتحدث الجميع عن MVC ، لاحظت أن قواعد العمل لا يتم معالجتها. في الأيام الخوالي للهندسة المعمارية الثلاثة ، كانت قواعد العمل في الطبقة الوسطى. أين يقعون في MVC الجديد؟

Answer 1

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

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

Answer 2

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

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

Answer 3

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

يعد وضع منطق العمل في العرض أمرًا سيئًا لأنه يربط الهيكل بالعرض التقديمي.

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

Answer 4

اقتباس من ويكيبيديا مقالة - سلعة:

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

Answer 5

هل هناك أي سبب لماذا لا يمكنك مزج MVC و Ntier؟ تطبيقنا يفعل ذلك. يتم استخدام وحدات التحكم الخاصة بنا للتحقق من صحة البيانات وتحديد مكالمات طبقة الأعمال التي يجب إجراءها.

ourapp.web - مشروع ASP.NET MVC
Ourapp.business - مكتبة طبقة الأعمال
ourapp.dataAccess - مكتبة طبقة البيانات
Ourapp.entities - في الأساس جميع النماذج التي تشاركها جميع الطبقات

Answer 6

يجب أن تكون قواعد العمل في النموذج ، وليس وحدة التحكم. وحدة التحكم والعرض هي جزء من طبقة العرض التقديمي.

يمثل النموذج كيانات المجال ووظائفه ..

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

Answer 7

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

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

Answer 8

أعتقد أن القضية هي مسألة تعريف. يبدو لي أن منطق تقديم الشاشات بالترتيب المطلوب هو مشكلة وحدة تحكم ، وقد رأيت بعض المشاريع التي تستخدم محرك القواعد لتحديد الطلب وما هو مطلوب من المستخدم. هذا ليس هو نفسه قواعد العمل IMHO.

Answer 9

يا رفاق مخطئون لأن قواعد العمل تعيش داخل وحدة التحكم وليس النموذج ...