ما هو MVP وMVC وما الفرق؟
https://stackoverflow.com/questions/2056
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
عند النظر إلى ما هو أبعد من راد طريقة (السحب والإفلات والتكوين) لبناء واجهات المستخدم التي تشجعك عليها العديد من الأدوات، من المحتمل أن تصادف ثلاثة أنماط تصميم تسمى تحكم عرض نموذج, نموذج عرض مقدم و نموذج-عرض-ViewModel.سؤالي يتكون من ثلاثة أجزاء:
- ما هي القضايا التي تعالجها هذه الأنماط؟
- كيف يتشابهون؟
- كيف هم مختلفون؟
المحلول
نموذج عرض مقدم
في أفضل لاعب, ، يحتوي المقدم على منطق عمل واجهة المستخدم للعرض.جميع الدعوات من مندوب العرض مباشرة إلى المقدم.يتم أيضًا فصل المقدم مباشرةً عن العرض ويتحدث إليه من خلال واجهة.هذا للسماح بالسخرية من العرض في اختبار الوحدة.إحدى السمات الشائعة لـ MVP هي أنه يجب أن يكون هناك الكثير من عمليات الإرسال في الاتجاهين.على سبيل المثال، عندما ينقر شخص ما على الزر "حفظ"، يقوم معالج الحدث بتفويض أسلوب "OnSave" الخاص بالمقدم.بمجرد اكتمال الحفظ، سيقوم مقدم العرض بعد ذلك باستدعاء العرض من خلال واجهته حتى يتمكن العرض من عرض أن الحفظ قد اكتمل.
يميل MVP إلى أن يكون نمطًا طبيعيًا جدًا لتحقيق عرض تقديمي منفصل في نماذج الويب.والسبب هو أن طريقة العرض يتم إنشاؤها دائمًا أولاً بواسطة وقت تشغيل ASP.NET.أنت تستطيع اكتشف المزيد عن كلا الخيارين.
اثنين من الاختلافات الأساسية
عرض سلبي: العرض غبي قدر الإمكان ويحتوي على منطق صفر تقريبًا.المقدم هو وسيط يتحدث إلى العرض والنموذج.العرض والنموذج محميان تمامًا من بعضهما البعض.قد يثير النموذج أحداثًا، لكن مقدم العرض يشترك فيها لتحديث طريقة العرض.في طريقة العرض الخاملة لا يوجد ربط مباشر للبيانات، وبدلاً من ذلك يعرض العرض خصائص الضبط التي يستخدمها مقدم العرض لتعيين البيانات.تتم إدارة جميع الحالات في المقدم وليس في طريقة العرض.
- طليعة:الحد الأقصى لسطح قابلية الاختبار؛الفصل النظيف بين العرض والنموذج
- يخدع:مزيد من العمل (على سبيل المثال جميع خصائص الضبط) حيث تقوم بربط جميع البيانات بنفسك.
المراقب المالي المشرف: يتعامل المقدم مع إيماءات المستخدم.يرتبط العرض بالنموذج مباشرة من خلال ربط البيانات.في هذه الحالة، تكون مهمة المقدم هي تمرير النموذج إلى العرض حتى يتمكن من الارتباط به.سيحتوي المقدم أيضًا على منطق للإيماءات مثل الضغط على الزر والتنقل وما إلى ذلك.
- طليعة:من خلال الاستفادة من ربط البيانات يتم تقليل كمية التعليمات البرمجية.
- يخدع:هناك سطح أقل قابلية للاختبار (بسبب ربط البيانات)، ويوجد تغليف أقل في العرض لأنه يتحدث مباشرة إلى النموذج.
تحكم عرض نموذج
في ال MVC, ، يكون جهاز التحكم مسؤولاً عن تحديد طريقة العرض التي سيتم عرضها استجابة لأي إجراء بما في ذلك عند تحميل التطبيق.وهذا يختلف عن MVP حيث يتم توجيه الإجراءات عبر العرض إلى المقدم.في MVC، يرتبط كل إجراء في العرض باستدعاء وحدة التحكم بالإضافة إلى الإجراء.يتضمن كل إجراء في الويب استدعاء عنوان URL على الجانب الآخر حيث يوجد وحدة تحكم تستجيب.بمجرد انتهاء وحدة التحكم هذه من المعالجة، ستعيد العرض الصحيح.يستمر التسلسل بهذه الطريقة طوال عمر التطبيق:
Action in the View
-> Call to Controller
-> Controller Logic
-> Controller returns the View.
أحد الاختلافات الكبيرة الأخرى في MVC هو أن العرض لا يرتبط مباشرة بالنموذج.يتم عرض العرض ببساطة، وهو عديم الحالة تمامًا.في تطبيقات MVC، عادةً لن يكون للعرض أي منطق في الكود الموجود خلفه.وهذا يتعارض مع MVP حيث يكون ذلك ضروريًا للغاية، لأنه إذا لم يتم تفويض العرض إلى المقدم، فلن يتم استدعاؤه أبدًا.
نموذج العرض
أحد الأنماط الأخرى التي يجب النظر إليها هو نموذج العرض نمط.في هذا النمط لا يوجد مقدم.بدلاً من ذلك، يرتبط العرض مباشرةً بنموذج العرض التقديمي.نموذج العرض التقديمي هو نموذج تم تصميمه خصيصًا للعرض.وهذا يعني أن هذا النموذج يمكن أن يكشف عن خصائص لا يمكن لأحد أن يضعها على نموذج المجال أبدًا لأنه سيكون انتهاكًا لفصل الاهتمامات.في هذه الحالة، يرتبط نموذج العرض التقديمي بنموذج المجال، وقد يشترك في الأحداث القادمة من هذا النموذج.يقوم العرض بعد ذلك بالاشتراك في الأحداث الواردة من نموذج العرض التقديمي ويقوم بتحديث نفسه وفقًا لذلك.يمكن لنموذج العرض التقديمي الكشف عن الأوامر التي يستخدمها العرض لاستدعاء الإجراءات.تتمثل ميزة هذا الأسلوب في أنه يمكنك بشكل أساسي إزالة التعليمات البرمجية الخلفية تمامًا حيث يقوم PM بتغليف جميع سلوكيات العرض بالكامل.يعد هذا النمط مرشحًا قويًا جدًا للاستخدام في تطبيقات WPF ويسمى أيضًا نموذج-عرض-ViewModel.
هناك مقالة MSDN حول نموذج العرض التقديمي وقسم في إرشادات التطبيق المركب لـ WPF (البريزم السابق) عنه أنماط العرض المنفصلة
نصائح أخرى
يعد هذا تبسيطًا مبالغًا فيه للمتغيرات العديدة لأنماط التصميم هذه، ولكن هذه هي الطريقة التي أحب أن أفكر بها في الاختلافات بين الاثنين.
MVC
أفضل لاعب
لقد قمت بالتدوين حول هذا الأمر منذ فترة، نقلا عن مشاركة تود سنايدر الممتازة حول الفرق بين الاثنين:
فيما يلي الاختلافات الرئيسية بين الأنماط:
نمط MVP
- العرض أكثر ارتباطًا بالنموذج.مقدم العرض مسؤول عن ربط النموذج بالعرض.
- أسهل في اختبار الوحدة لأن التفاعل مع العرض هو من خلال واجهة
- عادةً ما يتم عرض خريطة مقدم العرض واحدًا لواحد.قد يكون للآراء المعقدة مقدمي العروض متعددة.
نمط MVC
- تعتمد وحدة التحكم على سلوكيات ويمكن مشاركتها عبر طرق العرض
- يمكن أن يكون مسؤولاً عن تحديد طريقة العرض التي سيتم عرضها
إنه أفضل تفسير يمكن أن أجده على الويب.
وفيما يلي الرسوم التوضيحية التي تمثل تدفق الاتصالات
أفضل لاعب هو لا بالضرورة سيناريو حيث يكون العرض هو المسؤول (انظر MVP الخاص بـ Taligent على سبيل المثال).
أجد أنه من المؤسف أن الناس ما زالوا يبشرون بهذا كنمط (العرض المسؤول) بدلاً من النمط المضاد لأنه يتناقض مع "إنها مجرد وجهة نظر" (المبرمج العملي).تنص عبارة "إنها مجرد طريقة عرض" على أن العرض النهائي الذي يظهر للمستخدم هو مصدر قلق ثانوي للتطبيق.يجعل نمط MVP الخاص بشركة Microsoft إعادة استخدام طرق العرض أكثر صعوبة وصعوبة ملائم يعفي مصمم مايكروسوفت من تشجيع الممارسات السيئة.
لأكون صريحًا تمامًا، أعتقد أن المخاوف الأساسية لـ MVC تنطبق على أي تطبيق MVP وأن الاختلافات تكاد تكون دلالية بالكامل.طالما أنك تتبع فصل الاهتمامات بين العرض (الذي يعرض البيانات)، ووحدة التحكم (التي تبدأ تفاعل المستخدم وتتحكم فيه) والنموذج (البيانات و/أو الخدمات الأساسية)) فإنك تحقق فوائد MVC .إذا كنت تحقق الفوائد، فمن يهتم حقًا بما إذا كان نمطك هو MVC أو MVP أو وحدة التحكم المشرفة؟الوحيد حقيقي يبقى النمط كـ MVC، والباقي مجرد نكهات مختلفة منه.
يعتبر هذا مقالة مثيرة للغاية تسرد بشكل شامل عددًا من هذه التطبيقات المختلفة.قد تلاحظ أنهم جميعًا يفعلون نفس الشيء بشكل أساسي ولكن بشكل مختلف قليلاً.
أنا شخصياً أعتقد أن MVP قد تم إعادة تقديمه مؤخرًا كمصطلح جذاب إما لتقليل الحجج بين المتعصبين الدلالي الذين يتجادلون حول ما إذا كان شيء ما هو MVC حقًا أم لا أو لتبرير أدوات تطوير التطبيقات السريعة من Microsoft.لا يبرر أي من هذه الأسباب في كتبي وجوده كنمط تصميم منفصل.
أفضل لاعب:الرأي هو المسؤول.
العرض، في معظم الحالات، ينشئ مقدمه.سوف يتفاعل المقدم مع النموذج ويتعامل مع العرض من خلال واجهة.سيتفاعل العرض أحيانًا مع المقدم، عادةً من خلال بعض الواجهات.هذا يأتي إلى التنفيذ؛هل تريد أن يقوم العرض باستدعاء الأساليب على مقدم العرض أم تريد أن يشتمل العرض على أحداث يستمع إليها مقدم العرض؟يتلخص الأمر في هذا:الرأي يعرف عن المقدم.وجهة النظر تؤول إلى مقدم العرض.
الحد الأقصى للقيمة:وحدة التحكم هي المسؤولة.
يتم إنشاء وحدة التحكم أو الوصول إليها بناءً على بعض الأحداث/الطلبات.تقوم وحدة التحكم بعد ذلك بإنشاء العرض المناسب وتتفاعل مع النموذج لتكوين العرض بشكل أكبر.يتلخص في:تقوم وحدة التحكم بإنشاء العرض وإدارته؛الرأي تابع لوحدة التحكم.الرأي لا يعرف عن وحدة التحكم.
MVC (وحدة التحكم في عرض النموذج)
يتم توجيه الإدخال إلى وحدة التحكم أولاً، وليس إلى العرض.قد يأتي هذا الإدخال من مستخدم يتفاعل مع الصفحة، ولكن قد يكون أيضًا من مجرد إدخال عنوان URL محدد في المتصفح.في كلتا الحالتين، إنها وحدة تحكم يتم التواصل معها لبدء بعض الوظائف.هناك علاقة متعددة بين وحدة التحكم والعرض.وذلك لأن وحدة تحكم واحدة قد تحدد طرق عرض مختلفة ليتم عرضها بناءً على العملية التي يتم تنفيذها.لاحظ السهم ذو الاتجاه الواحد من وحدة التحكم إلى العرض.وذلك لأن العرض ليس لديه أي معرفة أو إشارة إلى وحدة التحكم.يقوم جهاز التحكم بتمرير النموذج مرة أخرى، لذلك هناك معرفة بين العرض والنموذج المتوقع الذي يتم تمريره إليه، ولكن لا يقوم جهاز التحكم بتقديمه.
MVP (مقدم العرض النموذجي)
يبدأ الإدخال بالعرض، وليس بالمقدم.يوجد تعيين واحد لواحد بين طريقة العرض والمقدم المرتبط.العرض يحمل إشارة إلى مقدم العرض.يتفاعل المقدم أيضًا مع الأحداث التي يتم تشغيلها من العرض، لذا فهو على علم بالعرض المرتبط به.يقوم المقدم بتحديث طريقة العرض بناءً على الإجراءات المطلوبة التي ينفذها على النموذج، ولكن طريقة العرض ليست على علم بالنموذج.
للمزيد من مرجع
هناك العديد من الإجابات على هذا السؤال، لكنني شعرت أن هناك حاجة إلى إجابة بسيطة حقًا تقارن بين الاثنين بشكل واضح.إليك المناقشة التي أجريتها عندما يبحث أحد المستخدمين عن اسم فيلم في تطبيق MVP وMVC:
مستخدم:صوت نقر …
منظر:من هو الذي؟[أفضل لاعب|MVC]
مستخدم:لقد ضغطت للتو على زر البحث ...
منظر:حسنًا ، انتظر لحظة ….[أفضل لاعب|MVC]
( منظر استدعاء مقدم|مراقب … ) [أفضل لاعب|MVC]
منظر:يا مقدم|مراقب, ، لقد قام المستخدم للتو بالنقر فوق زر البحث، فماذا أفعل؟[أفضل لاعب|MVC]
مقدم|مراقب:يا منظر, هل هناك أي مصطلح بحث في تلك الصفحة؟[أفضل لاعب|MVC]
منظر:نعم،... ها هو ... "بيانو" [أفضل لاعب|MVC]
مقدم:شكرًا منظر،... وفي الوقت نفسه أبحث عن مصطلح البحث في نموذج, ، يرجى إظهار شريط التقدم له/لها [أفضل لاعب|MVC]
( مقدم|مراقب يدعو نموذج … ) [أفضل لاعب|MVC]
مقدم|مراقب:يا نموذج, ، هل لديك أي تطابق لمصطلح البحث هذا؟:"بيانو" [أفضل لاعب|MVC]
نموذج:يا مقدم|مراقب, ، دعني أتحقق … [أفضل لاعب|MVC]
( نموذج يجري استعلامًا إلى قاعدة بيانات الأفلام...) [أفضل لاعب|MVC]
( بعد حين ...)
-------------- هنا يبدأ التباين بين MVP وMVC ---------------
نموذج:لقد وجدت لك قائمة، مقدم, ، هنا هو في JSON "[{"name": "معلم البيانو"، "السنة": 2001}، {"name": "بيانو"، "السنة": 1993}]" [أفضل لاعب]
نموذج:هناك بعض النتائج المتاحة، مراقب.لقد قمت بإنشاء متغير حقل في المثيل الخاص بي وملأته بالنتيجة.اسمها هو "searchResultsList" [MVC]
(مقدم|مراقب شكرًا نموذج ويعود إلى منظر) [أفضل لاعب|MVC]
مقدم:شكرا على الانتظار منظر, ، لقد وجدت لك قائمة بالنتائج المطابقة وقمت بترتيبها بتنسيق قابل للعرض:["مدرس بيانو 2001"، "بيانو 1993"].يرجى إظهاره للمستخدم في قائمة عمودية.يرجى أيضًا إخفاء شريط التقدم الآن [أفضل لاعب]
مراقب:شكرا على الانتظار منظر, ، لقد طلبت نموذج حول استعلام البحث الخاص بك.تقول إنها عثرت على قائمة بالنتائج المطابقة وقمت بتخزينها في متغير يسمى "searchResultsList" داخل مثيلها.يمكنك الحصول عليه من هناك.يرجى أيضًا إخفاء شريط التقدم الآن [MVC]
منظر:شكراً جزيلاً مقدم [أفضل لاعب]
منظر:شكرا لك "التحكم" [MVC] (الآن منظر يتساءل في نفسه:كيف يجب أن أقدم النتائج التي أحصل عليها من نموذج للمستخدم؟هل يجب أن تأتي سنة إنتاج الفيلم أولا أم أخيرا...؟هل يجب أن تكون في قائمة رأسية أم أفقية؟...)
في حال كنت مهتمًا، فقد قمت بكتابة سلسلة من المقالات تتناول الأنماط المعمارية للتطبيقات (MVC، MVP، MVVP، الهندسة النظيفة، ...) مصحوبة بمستودع Github هنا.على الرغم من أن العينة مكتوبة لنظام Android، إلا أنه يمكن تطبيق المبادئ الأساسية على أي وسيط.
- MVP = نموذج العرض-المقدم
MVC = وحدة تحكم عرض النموذج
- كلا أنماط العرض.إنها تفصل التبعيات بين النموذج (فكر في كائنات المجال)، والشاشة/صفحة الويب الخاصة بك (العرض)، وكيف من المفترض أن تتصرف واجهة المستخدم الخاصة بك (المقدم/وحدة التحكم)
- إنها متشابهة إلى حد ما في المفهوم، حيث يقوم الأشخاص بتهيئة مقدم العرض/وحدة التحكم بشكل مختلف حسب الذوق.
- مقالة عظيمة عن الاختلافات هنا.أبرزها هو أن نمط MVC يحتوي على نموذج يقوم بتحديث العرض.
ومن الجدير بالذكر أيضًا أن هناك أنواعًا مختلفة من أفضل اللاعبين أيضًا.قام فاولر بتقسيم النمط إلى قسمين - العرض السلبي ووحدة التحكم المشرفة.
عند استخدام العرض السلبي، يقوم العرض الخاص بك عادةً بتنفيذ واجهة دقيقة مع تعيين الخصائص بشكل مباشر إلى عنصر واجهة المستخدم الأساسي.على سبيل المثال، قد يكون لديك ICustomerView بخصائص مثل الاسم والعنوان.
قد يبدو التنفيذ الخاص بك كما يلي:
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
سيتحدث فصل مقدم العرض الخاص بك إلى النموذج و"يعينه" للعرض.ويسمى هذا النهج "العرض السلبي".والفائدة هي أن العرض سهل الاختبار، ومن الأسهل التنقل بين منصات واجهة المستخدم (الويب، Windows/XAML، وما إلى ذلك).العيب هو أنه لا يمكنك الاستفادة من أشياء مثل ربط البيانات (وهو حقًا قوية في أطر مثل WPF و سيلفرلايت).
النكهة الثانية لـ MVP هي وحدة التحكم المشرف.في هذه الحالة، قد يشتمل العرض الخاص بك على خاصية تسمى "العميل"، والتي ترتبط مرة أخرى ببيانات عناصر واجهة المستخدم.لا يتعين عليك التفكير في مزامنة العرض وإدارته بشكل دقيق، ويمكن لوحدة التحكم المشرف التدخل والمساعدة عند الحاجة، على سبيل المثال من خلال منطق التفاعل المتكامل.
"النكهة" الثالثة لـ MVP (أو ربما يسميها شخص ما نمطًا منفصلاً) هي نموذج العرض (أو يشار إليه أحيانًا بـ Model-View-ViewModel).بالمقارنة مع MVP، فإنك "تدمج" M وP في فئة واحدة.لديك كائن العميل الخاص بك والذي تكون عناصر واجهة المستخدم الخاصة بك مرتبطة بالبيانات، ولكن لديك أيضًا حقول إضافية خاصة بواجهة المستخدم مثل "IsButtonEnabled" أو "IsReadOnly"، وما إلى ذلك.
أعتقد أن أفضل مورد وجدته لهندسة واجهة المستخدم هو سلسلة منشورات المدونة التي قام بها جيريمي ميلر في قم بإنشاء جدول محتويات سلسلة CAB الخاصة بك.لقد غطى جميع نكهات MVP وأظهر كود C# لتنفيذها.
لقد قمت أيضًا بالتدوين حول نمط Model-View-ViewModel في سياق Silverlight إعادة زيارة YouCard:تنفيذ نمط ViewModel.
تحكم عرض نموذج
MVC هو نمط لهندسة تطبيق برمجي.فهو يفصل منطق التطبيق إلى ثلاثة أجزاء منفصلة، مما يعزز النمطية وسهولة التعاون وإعادة الاستخدام.كما أنه يجعل التطبيقات أكثر مرونة وترحيبًا بالتكرارات. فهو يفصل التطبيق إلى المكونات التالية:
- عارضات ازياء للتعامل مع البيانات ومنطق الأعمال
- وحدات التحكم للتعامل مع واجهة المستخدم والتطبيق
- الآراء للتعامل مع كائنات واجهة المستخدم الرسومية والعرض التقديمي
لجعل هذا الأمر أكثر وضوحًا، دعونا نتخيل تطبيقًا بسيطًا لقائمة التسوق.كل ما نريده هو قائمة بالاسم والكمية والسعر لكل عنصر نحتاج إلى شرائه هذا الأسبوع.سنصف أدناه كيف يمكننا تنفيذ بعض هذه الوظائف باستخدام MVC.
نموذج عرض مقدم
- ال نموذج هي البيانات التي سيتم عرضها في طريقة العرض (واجهة المستخدم).
- ال منظر هي واجهة تعرض البيانات (النموذج) وتوجه أوامر المستخدم (الأحداث) إلى المقدم للعمل بناءً على تلك البيانات.عادةً ما يحتوي العرض على إشارة إلى مقدمه.
- ال مقدم هو "الرجل الوسيط" (الذي يلعبه جهاز التحكم في MVC) وله إشارات إلى كل من العرض والنموذج. يرجى ملاحظة أن كلمة "نموذج" مضللة.ينبغي أن يكون بالأحرى منطق الأعمال الذي يسترد النموذج أو يعالجه.على سبيل المثال:إذا كانت لديك قاعدة بيانات تخزن المستخدم في جدول قاعدة بيانات وكان العرض الخاص بك يريد عرض قائمة بالمستخدمين، فسيكون لدى المقدم مرجع إلى منطق أعمال قاعدة البيانات الخاصة بك (مثل DAO) حيث سيقوم المقدم بالاستعلام عن قائمة المستخدمين.
إذا كنت تريد رؤية عينة مع تنفيذ بسيط يرجى التحقق هذا مشاركة جيثب
يمكن أن يعمل سير العمل الملموس للاستعلام عن قائمة المستخدمين وعرضها من قاعدة بيانات على النحو التالي:
ما هو اختلاف بين MVC و أفضل لاعب أنماط؟
نمط MVC
تعتمد وحدة التحكم على السلوكيات ويمكن مشاركتها عبر طرق العرض
يمكن أن يكون مسؤولاً عن تحديد العرض الذي سيتم عرضه (نمط وحدة التحكم الأمامية)
نمط MVP
العرض أكثر ارتباطًا بالنموذج.يكون المقدم مسؤولاً عن ربط النموذج بالعرض.
أسهل في اختبار الوحدة لأن التفاعل مع العرض يتم من خلال واجهة
عادةً ما يتم عرض خريطة مقدم العرض واحدًا لواحد.قد تحتوي طرق العرض المعقدة على عدة مقدمين.
يعالج كل منهم مشاكل مختلفة ويمكن دمجها معًا للحصول على شيء مثل ما يلي
يوجد ايضا مقارنة كاملة بين MVC وMVP وMVVM هنا
يهدف كلا الإطارين إلى الفصل بين الاهتمامات - على سبيل المثال، التفاعل مع مصدر البيانات (النموذج)، ومنطق التطبيق (أو تحويل هذه البيانات إلى معلومات مفيدة) (المتحكم/المقدم) وكود العرض (العرض).في بعض الحالات، يمكن أيضًا استخدام النموذج لتحويل مصدر البيانات إلى تجريد بمستوى أعلى أيضًا.وخير مثال على ذلك هو مشروع واجهة متجر MVC.
هناك مناقشة هنا فيما يتعلق بالاختلافات بين MVC و MVP.
الفرق الذي تم إجراؤه هو أنه في تطبيق MVC يكون العرض تقليديًا وتتفاعل وحدة التحكم مع النموذج، ولكن ليس مع بعضها البعض.
تتيح تصميمات MVP للمقدم الوصول إلى النموذج والتفاعل مع العرض.
بعد قولي هذا، يعد ASP.NET MVC بموجب هذه التعريفات إطار عمل MVP لأن وحدة التحكم تصل إلى النموذج لملء العرض الذي من المفترض ألا يحتوي على أي منطق (يعرض فقط المتغيرات التي توفرها وحدة التحكم).
ربما للحصول على فكرة عن تمييز ASP.NET MVC عن MVP، راجع ذلك هذا العرض التقديمي MIX بواسطة سكوت هانسيلمان.
كلاهما عبارة عن نمطين يحاولان الفصل بين العرض التقديمي ومنطق الأعمال، وفصل منطق الأعمال عن جوانب واجهة المستخدم
من الناحية المعمارية، MVP هو النهج القائم على وحدة التحكم في الصفحة حيث MVC هو النهج القائم على وحدة التحكم الأمامية.وهذا يعني أنه في MVP يتم تحسين دورة حياة صفحة نموذج الويب القياسي فقط عن طريق استخراج منطق العمل من التعليمات البرمجية الموجودة خلفه.بمعنى آخر، الصفحة هي التي تخدم طلب http.بمعنى آخر، MVP IMHO هو نوع تطوري من التحسين على شكل نموذج ويب.من ناحية أخرى ، يغير MVC اللعبة تمامًا لأن الطلب يتم اعتراضه بواسطة فئة وحدة التحكم قبل تحميل الصفحة ، ويتم تنفيذ منطق العمل هناك ، ثم في النتيجة النهائية لتحديد التحكم في البيانات التي تم إلقاؤها للتو على الصفحة ("عرض") في ذلك Sense ، MVC تبدو (على الأقل بالنسبة لي) الكثير للإشراف على نكهة وحدة التحكم من MVP المحسنة بمحرك التوجيه
كلاهما يمكّنان TDD ولهما سلبيات وإيجابيات.
يجب أن يعتمد القرار بشأن كيفية اختيار واحد منهم IMHO على مقدار الوقت المستثمر في نوع نموذج الويب ASP NET لتطوير الويب.إذا كان الشخص يعتبر نفسه جيدًا في نماذج الويب، فأنا أقترح عليه MVP.إذا لم يشعر المرء بالارتياح في أشياء مثل دورة حياة الصفحة وما إلى ذلك، فقد يكون MVC طريقة للذهاب إلى هنا.
إليك رابط آخر لنشر مدونة يقدم المزيد من التفاصيل حول هذا الموضوع
لقد استخدمت كلاً من MVP وMVC وعلى الرغم من أننا كمطورين نميل إلى التركيز على الاختلافات الفنية لكلا النموذجين، إلا أن نقطة MVP في IMHO ترتبط بسهولة التبني أكثر من أي شيء آخر.
إذا كنت أعمل ضمن فريق يتمتع بخلفية جيدة في أسلوب تطوير نماذج الويب، فمن الأسهل بكثير تقديم MVP بدلاً من MVC.أود أن أقول إن أفضل لاعب في هذا السيناريو يعد فوزًا سريعًا.
تخبرني تجربتي أن نقل الفريق من نماذج الويب إلى MVP ومن ثم من MVP إلى MVC أمر سهل نسبيًا؛يعد الانتقال من نماذج الويب إلى MVC أكثر صعوبة.
أترك هنا رابطًا لسلسلة من المقالات التي نشرها أحد أصدقائي حول MVP وMVC.
http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx
في MVP، يسحب العرض البيانات من المقدم الذي يرسم البيانات ويعدها/يقوم بتطبيعها من النموذج بينما في MVC، تقوم وحدة التحكم بسحب البيانات من النموذج وتعيينها، عن طريق الدفع في العرض.
في MVP، يمكنك الحصول على عرض واحد يعمل مع أنواع متعددة من مقدمي العروض ومقدم واحد يعمل مع طرق عرض متعددة ومختلفة.
يستخدم MVP عادةً نوعًا ما من إطار عمل الربط، مثل إطار عمل ربط Microsoft WPF أو أطر ربط متنوعة لـ HTML5 وJava.
في هذه الأطر، تكون واجهة المستخدم/HTML5/XAML على دراية بخاصية مقدم العرض التي يعرضها كل عنصر من عناصر واجهة المستخدم، لذا عندما تربط طريقة عرض بمقدم عرض، تبحث طريقة العرض عن الخصائص وتعرف كيفية استخلاص البيانات منها وكيف لتعيينها عند تغيير قيمة في واجهة المستخدم من قبل المستخدم.
لذلك، على سبيل المثال، إذا كان النموذج عبارة عن سيارة، فإن المقدم هو نوع من مقدم السيارة، ويكشف عن خصائص السيارة (السنة، الشركة المصنعة، المقاعد، وما إلى ذلك) للعرض.يعرف العرض أن حقل النص المسمى "صانع السيارة" يحتاج إلى عرض خاصية صانع المقدم.
يمكنك بعد ذلك ربط العديد من أنواع مقدمي العرض المختلفة بالعرض، ويجب أن تمتلك جميعها خاصية Maker - يمكن أن تكون طائرة أو قطارًا أو أي شيء آخر، ولا يهم العرض.يسحب العرض البيانات من المقدم - بغض النظر عن ذلك - طالما أنه ينفذ واجهة متفق عليها.
إطار الربط هذا، إذا قمت بتجريده، فهو في الواقع وحدة التحكم :-)
وهكذا، يمكنك النظر إلى MVP باعتباره تطورًا لـ MVC.
يعد MVC أمرًا رائعًا، لكن المشكلة هي أنه عادةً ما يكون جهاز التحكم الخاص به لكل عرض.تعرف وحدة التحكم "أ" كيفية تعيين حقول العرض "أ".إذا كنت تريد الآن أن يعرض العرض A بيانات النموذج B، فأنت بحاجة إلى وحدة التحكم A لمعرفة النموذج B، أو تحتاج إلى وحدة التحكم A لتلقي كائن بواجهة - وهو مثل MVP فقط بدون الارتباطات، أو تحتاج إلى إعادة الكتابة رمز مجموعة واجهة المستخدم في وحدة التحكم B.
الاستنتاج - يعد كل من MVP وMVC منفصلين عن أنماط واجهة المستخدم، لكن MVP عادةً ما يستخدم إطار عمل ربط وهو MVC تحته.وبالتالي فإن MVP على مستوى معماري أعلى من MVC ونمط غلاف أعلى من MVC.
وجهة نظري المتواضعة:MVP للمقاييس الكبيرة، وMVC للمقاييس الصغيرة.مع MVC، أشعر في بعض الأحيان أن V وC يمكن رؤيتهما كجانبين لمكون واحد غير قابل للتجزئة يرتبطان بشكل مباشر بـ M، وسيقع أحدهما حتمًا في هذا عند النزول إلى مقاييس أقصر، مثل عناصر تحكم واجهة المستخدم والأدوات الأساسية.في هذا المستوى من التفاصيل، فإن MVP لا معنى له.عندما يذهب المرء على العكس من ذلك إلى نطاقات أكبر، تصبح الواجهة المناسبة أكثر أهمية، وينطبق الشيء نفسه على التعيين الواضح للمسؤوليات، وهنا يأتي MVP.
من ناحية أخرى، قد يكون وزن قاعدة القياس هذه قليلًا جدًا عندما تفضل خصائص النظام الأساسي نوعًا ما من العلاقات بين المكونات، كما هو الحال مع الويب، حيث يبدو أن تنفيذ MVC أسهل من تنفيذ MVP.
هنالك هذا فيديو جميل من العم بوب حيث يشرح باختصار MVC وMVP في النهاية.
IMO، MVP هو نسخة محسنة من MVC حيث تقوم بشكل أساسي بفصل الاهتمام بما ستعرضه (البيانات) عن كيفية عرضه (العرض).يتضمن Presenter نوعًا ما منطق الأعمال الخاص بواجهة المستخدم الخاصة بك، ويفرض ضمنيًا البيانات التي يجب تقديمها ويمنحك قائمة بنماذج العرض الغبية.وعندما يحين وقت عرض البيانات، ما عليك سوى توصيل طريقة العرض الخاصة بك (ربما تتضمن نفس المعرف) في المحول الخاص بك وتعيين حقول العرض ذات الصلة باستخدام نماذج العرض هذه مع الحد الأدنى من التعليمات البرمجية التي يتم تقديمها (فقط باستخدام أدوات الضبط).وتتمثل الفائدة الرئيسية منها في أنه يمكنك اختبار منطق أعمال واجهة المستخدم الخاص بك مقابل طرق عرض متعددة/مختلفة مثل عرض العناصر في قائمة أفقية أو قائمة رأسية.
في MVC، نتحدث من خلال واجهات (حدود) للصق طبقات مختلفة.تعد وحدة التحكم مكونًا إضافيًا في بنيتنا ولكن ليس لديها مثل هذا القيد لفرض ما سيتم عرضه.وبهذا المعنى، يعد MVP نوعًا من MVC مع مفهوم طرق العرض التي يمكن توصيلها بوحدة التحكم عبر المحولات.
نأمل أن يساعد هذا بشكل أفضل.
هناك العديد من إصدارات MVC، هذه الإجابة تتعلق بـ MVC الأصلي في Smalltalk.باختصار، هو كذلك
هذا الكلام droidcon NYC 2017 - تصميم تطبيق نظيف باستخدام مكونات الهندسة المعمارية يوضح ذلك
أبسط إجابة هي كيفية تفاعل العرض مع النموذج.في MVP، يرتبط العرض بالمقدم، الذي يعمل كوسيط بين العرض والنموذج، حيث يأخذ المدخلات من العرض، ويحصل على البيانات من النموذج، ثم يقوم بتنفيذ منطق الأعمال وأخيرًا تحديث العرض.في MVC يقوم النموذج بتحديث العرض مباشرة بدلاً من الرجوع إلى وحدة التحكم.
أعتقد أن هذه الصورة لإروين فاندرفالك (والصور المصاحبة لها). شرط) هو أفضل شرح لـ MVC وMVP وMVVM وأوجه التشابه بينها والاختلاف بينها.ال شرط لا يظهر في نتائج محرك البحث للاستعلامات حول "MVC وMVP وMVVM" لأن عنوان المقالة لا يحتوي على الكلمتين "MVC" و"MVP"؛ولكن هذا هو أفضل تفسير، على ما أعتقد.
(ال شرط ويطابق أيضًا ما قاله العم بوب مارتن في إحدى أحاديثه:أن MVC تم تصميمه في الأصل لمكونات واجهة المستخدم الصغيرة، وليس لبنية النظام)
أفضل لاعب
يرمز MVP إلى النموذج - العرض - مقدم العرض.ظهر هذا في أوائل عام 2007 عندما قدمت Microsoft تطبيقات Windows Smart Client.
يعمل المقدم كدور إشرافي في MVP والذي يربط عرض الأحداث ومنطق الأعمال من النماذج.
سيتم تنفيذ ربط حدث العرض في Presenter من واجهة العرض.
يعد العرض هو البادئ لمدخلات المستخدم ثم يقوم بتفويض الأحداث إلى مقدم العرض ويتعامل مقدم العرض مع روابط الأحداث ويحصل على البيانات من النماذج.
الايجابيات:العرض هو فقط واجهة المستخدم ليس فقط أي منطق مستوى من قابلية الاختبار
سلبيات:معقدة بعض الشيء ومزيد من العمل عند تنفيذ ربط الأحداث
MVC
يرمز MVC إلى Model-View-Controller.وحدة التحكم مسؤولة عن إنشاء النماذج وعرض طرق العرض باستخدام النماذج الملزمة.
وحدة التحكم هي البادئ وهي التي تقرر العرض الذي سيتم تقديمه.
الايجابيات:التركيز على مبدأ المسؤولية الفردي مستوى عالٍ من قابلية الاختبار
سلبيات:في بعض الأحيان يكون هناك عبء عمل كبير جدًا على وحدات التحكم، إذا حاولت تقديم طرق عرض متعددة في نفس وحدة التحكم.
