design-patterns - شرح - mvc php




ما هي MVP و MVC وما الفرق؟ (16)

عند النظر إلى ما وراء طريقة RAD (السحب والإعداد) لبناء واجهات المستخدم ، فإن العديد من الأدوات تشجعك على الأرجح أن تصادف ثلاثة أنماط تصميم تسمى Model-View-Controller و Model-View-Presenter و Model-View-ViewModel . سؤالي له ثلاثة أجزاء:

  1. ما القضايا التي تتناولها هذه الأنماط؟
  2. كيف يتشابهون؟
  3. كيف هم مختلفون؟

نموذج للرؤية ومقدم

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

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

اثنين من الاختلافات الأساسية

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

  • برو: أقصى سطح اختبار ؛ فصل نظيف للعرض والموديل
  • Con: المزيد من العمل (على سبيل المثال جميع خصائص setter) كما تفعل جميع البيانات ملزمة نفسك.

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

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

تحكم عرض نموذج

في MVC ، تكون وحدة التحكم مسؤولة عن تحديد طريقة العرض التي سيتم عرضها استجابةً لأي إجراء بما في ذلك عند تحميل التطبيق. هذا يختلف عن MVP حيث يتم توجيه الإجراءات من خلال View to the Presenter. في MVC ، يرتبط كل إجراء في طريقة العرض بدعوة إلى وحدة تحكم مع إجراء. في الويب ، يتضمن كل إجراء مكالمة لعنوان URL على الجانب الآخر يوجد وحدة تحكم تستجيب. بمجرد اكتمال وحدة التحكم هذه معالجتها ، فسوف تُرجع العرض الصحيح. يستمر التسلسل بهذه الطريقة طوال عمر التطبيق:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

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

نموذج العرض

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

يوجد مقال MSDN حول نموذج العرض التقديمي وقسم في دليل التطبيق المركب لـ WPF (المنشور السابق) حول أنماط العروض التقديمية المنفصلة


MVP: الرأي هو المسؤول.

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

بعثة التحقق المشتركة: وحدة التحكم هي المسؤولة.

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


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

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

قد يبدو تطبيقك كالتالي:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

سيتحدث صف مقدم العرض الخاص بك عن النموذج و "يعينه" إلى العرض. هذا النهج يسمى "المنظر السلبي". الفائدة هي أن العرض سهل الاختبار ، وأنه من السهل التنقل بين منصات واجهة المستخدم (الويب ، Windows / XAML ، إلخ). العيب هو أنه لا يمكنك الاستفادة من أشياء مثل ربط البيانات (وهي قوية بالفعل في أطر مثل WPF و Silverlight ).

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

"النكهة" الثالثة لـ MVP (أو ربما يسميها شخص ما نمطًا منفصلاً) هي "نموذج العرض التقديمي" (أو يشار إليه أحيانًا باسم Model-View-ViewModel). بالمقارنة مع MVP ، يمكنك "دمج" M و P في فئة واحدة. لديك كائن عميل لديك وهو عبارة عن عناصر واجهة مستخدم UI مرتبطة ببياناتك ، ولكن لديك أيضًا حقول إضافية خاصة بـ UI مثل "IsButtonEnabled" أو "IsReadOnly" ، إلخ.

أعتقد أن أفضل مورد وجدته لهندسة واجهة المستخدم هو سلسلة من منشورات المدونة التي قام بها جيريمي ميلر في جدول محتويات The Build Your Own CAB Series . قام بتغطية جميع نكهات MVP وأظهر رمز C # لتنفيذها.

لقد قمت أيضًا بالتدوين حول نموذج Model-View-ViewModel في سياق Silverlight عبر YouCard Re-visit: تطبيق نمط ViewModel .


في MVP ، يقوم العرض بسحب البيانات من مقدم العرض الذي يقوم بسحب وإعداد / تطبيع البيانات من النموذج بينما في MVC تقوم وحدة التحكم بسحب البيانات من النموذج وتعيينها ، من خلال الدفع في العرض.

في MVP ، يمكن أن يكون لديك عرض واحد يعمل مع أنواع متعددة من مقدمي العروض ومقدم واحد يعمل مع طرق عرض متعددة مختلفة.

عادةً ما يستخدم MVP نوعًا من إطار عمل الربط ، مثل إطار ربط Microsoft WPF أو أطر عمل ربط متعددة لـ HTML5 و Java.

في تلك الأطر ، يدرك UI / HTML5 / XAML ، ما هي خاصية مقدم العرض التي يعرضها كل عنصر من عناصر واجهة المستخدم ، لذلك عندما تربط طريقة عرض مع مقدم عرض ، فإن طريقة العرض تبحث عن الخصائص وتعرف كيفية استخلاص البيانات منها وكيفية لتعيينهم عند تغيير قيمة في واجهة المستخدم من قبل المستخدم.

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

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

إطار الربط هذا ، إذا قمت بتجريده ، فهو في الواقع جهاز التحكم :-)

وهكذا ، يمكنك النظر إلى MVP كتطور في MVC.

MVC كبيرة ، ولكن المشكلة هي أن وحدة التحكم عادةً لكل عرض. تعرف وحدة التحكم A كيفية تعيين حقول طريقة العرض A. إذا كنت تريد الآن أن تعرض طريقة العرض A بيانات النموذج B ، فأنت بحاجة إلى وحدة التحكم A لمعرفة طراز B ، أو تحتاج إلى وحدة التحكم A لتلقي كائن بواجهة - يشبه ذلك MVP فقط دون الارتباطات ، أو تحتاج إلى إعادة كتابة رمز مجموعة واجهة المستخدم في وحدة التحكم ب.

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


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

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

تخبرني تجربتي أن نقل فريق من نماذج الويب إلى MVP ثم من MVP إلى MVC سهل نسبيًا ؛ يعد الانتقال من نماذج الويب إلى MVC أكثر صعوبة.

أترك هنا رابطًا لسلسلة من المقالات التي نشرها صديق لي حول MVP و MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx


لقد قمت بالتدوين حول هذا الأمر منذ فترة ، أقتبس من مقالة تود سنايدر الممتازة عن الفرق بين الاثنين :

فيما يلي الاختلافات الرئيسية بين الأنماط:

نمط MVP

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

نمط MVC

  • تعتمد أداة التحكم على السلوكيات ويمكن مشاركتها عبر طرق العرض
  • يمكن أن يكون مسؤولا عن تحديد أي عرض لعرضه

إنه أفضل تفسير على الويب يمكن أن أجده.


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

مستخدم: انقر فوق انقر فوق ...

عرض : من هذا؟ [ MVP | MVC ]

المستخدم: لقد قمت فقط بالنقر فوق زر البحث ...

عرض : حسنًا ، امسك ثانية ... [ MVP | MVC ]

( عرض استدعاء مقدم | تحكم ...) [ MVP | MVC ]

عرض : يا مقدم | المراقب المالي ، لقد نقر المستخدم للتو على زر البحث ، ماذا أفعل؟ [ MVP | MVC ]

مقدم | المراقب المالي : يا عرض ، هل هناك أي مصطلح بحث في تلك الصفحة؟ [ MVP | MVC ]

عرض : نعم ، ... ها هو ... "بيانو" [ MVP | MVC ]

المقدم : شكرًا جزيلاً للعرض ، ... في الوقت نفسه أبحث عن مصطلح البحث في النموذج ، يرجى أن يُظهر له / لها شريط تقدم [ MVP | MVC ]

( مقدم | وحدة تحكم تدعو النموذج ...) [ MVP | MVC ]

مقدم | المراقب المالي : يا موديل ، هل لديك أي تطابق مع مصطلح البحث ؟: "بيانو" [ MVP | MVC ]

نموذج : يا مقدم | المراقب المالي ، اسمحوا لي أن تحقق ... [ MVP | MVC ]

(يُجري Model استعلامًا في قاعدة بيانات الأفلام ...) [ MVP | MVC ]

( بعد قليل ... )

-------------- هذا هو المكان الذي تبدأ فيه MVP و MVC في التباعد ---------------

النموذج : لقد وجدت قائمة لك ، مقدم ، هنا في JSON "[{" name ":" Piano Teacher "،" year ": 2001} ، {" name ":" Piano "،" year ": 1993} ] "[ MVP ]

نموذج : هناك بعض النتائج المتاحة ، المراقب المالي . لقد قمت بإنشاء متغير حقل في حالتي وملؤه بالنتيجة. إنه الاسم "searchResultsList" [ MVC ]

( مقدم | مراقب يشكر النموذج ويعود إلى المنظر ) [ MVP | MVC ]

المقدم : شكرًا على انتظار المشاهدة ، لقد وجدت قائمة من النتائج المطابقة لك ورتبتها بتنسيق مناسب: ["Piano Teacher 2001"، "Piano 1993"]. يرجى إظهارها للمستخدم في قائمة رأسية. يرجى أيضًا إخفاء شريط التقدم الآن [ MVP ]

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

عرض : شكرًا جزيلاً على مقدم العرض [ MVP ]

عرض : شكرًا لك "المراقب المالي" [ MVC ] (الآن ، طريقة العرض تسأل نفسها: كيف يمكنني تقديم النتائج التي أحصل عليها من النموذج إلى المستخدم؟ هل يجب أن تأتي سنة إنتاج الفيلم أولاً أو آخر ...؟ يكون في قائمة رأسية أو أفقية؟ ...)

في حال كنت مهتمًا ، كنت أكتب سلسلة من المقالات التي تتعامل مع الأنماط المعمارية للتطبيق (MVC ، MVP ، MVVP ، الهندسة المعمارية النظيفة ، ...) برفقة Github repo here . على الرغم من أن العينة مكتوبة لنظام أندرويد ، إلا أنه يمكن تطبيق المبادئ الأساسية على أي وسيط.


وهنا الرسوم التوضيحية التي تمثل تدفق الاتصالات




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

هناك مناقشة here بخصوص الاختلافات بين MVC و MVP.

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

تصميمات MVP تتيح للمقدم الوصول إلى النموذج والتفاعل مع العرض.

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

للحصول على فكرة عن تمييز ASP.NET MVC عن MVP ، تحقق من عرض MIX هذا بواسطة Scott Hanselman.


MVC (جهاز التحكم في عرض النماذج)

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

MVP (مقدم عرض نموذج)

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

لمزيد من Reference


تحكم عرض نموذج

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

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

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

نموذج للرؤية ومقدم

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

إذا كنت تريد أن ترى عينة مع تنفيذ بسيط يرجى التحقق من this المنصب GitHub

يمكن أن يعمل سير عمل ملموس لاستعلام وعرض قائمة المستخدمين من قاعدة بيانات مثل هذا:

ما هو الفرق بين أنماط MVC و MVP ؟

نمط MVC

  • تعتمد أداة التحكم على السلوكيات ويمكن مشاركتها عبر طرق العرض

  • يمكن أن يكون مسؤولاً عن تحديد طريقة العرض التي سيتم عرضها (نمط وحدة التحكم الأمامية)

نمط MVP

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

  • أسهل في اختبار الوحدة لأن التفاعل مع العرض يتم من خلال واجهة

  • عادة عرض مقدم خريطة واحد إلى واحد. وجهات النظر المعقدة قد يكون لها العديد من مقدمي العروض.


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



وأعتقد أن هذه الصورة عن طريق اروين Vandervalk (والمرافق article ) هي أفضل تفسير لMVC، MVP، وMVVM، أوجه التشابه بينها، وخلافاتهم. و article لا تظهر في نتائج محرك البحث للاستعلامات على "MVC، MVP، وMVVM" لأن عنوان المقال لا يحتوي على عبارة "MVC" و "MVP". ولكن هذا هو أفضل تفسير ، على ما أعتقد.

( تتطابق article أيضًا مع ما قاله العم بوب مارتن في أحد محادثاته: تم تصميم MVC في الأصل لمكونات واجهة المستخدم الصغيرة ، وليس لبنية النظام)


يوجد this الفيديو الجميل من العم بوب حيث يشرح بإيجاز MVC & MVP في النهاية.

IMO ، MVP هو نسخة محسنة من MVC ، حيث تقوم بشكل أساسي بفصل قلق ما ستظهره (البيانات) عن كيفية عرضك (العرض). يتضمن مقدم العرض كيندا منطق العمل الخاص بواجهة المستخدم الخاصة بك ، ويفرض ضمنا ما هي البيانات التي ينبغي تقديمها ويمنحك قائمة من نماذج العرض الغبية. وعندما يحين الوقت لإظهار البيانات ، يمكنك ببساطة توصيل طريقة العرض الخاصة بك (ربما تتضمن نفس المعرِّف) في المحول وتعيين حقول العرض ذات الصلة باستخدام طرز العرض هذه مع إدخال حد أدنى من الكود (فقط باستخدام أدوات التثبيت). الفائدة الرئيسية هي أنه يمكنك اختبار منطق أعمال واجهة المستخدم الخاص بك مقابل العديد من / طرق العرض المختلفة مثل إظهار العناصر في قائمة أفقية أو قائمة رأسية.

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

آمل أن يكون هذا يساعد بشكل أفضل.


  • MVP = نموذج عرض مقدم
  • MVC = نموذج عرض المراقب

    1. كلا أنماط العرض. إنها تفصل التبعيات بين النموذج (فكر في كائنات المجال) ، وشاشتك / صفحة الويب (العرض) ، وكيف من المفترض أن تتصرف واجهة المستخدم الخاصة بك (مقدم / وحدة تحكم)
    2. تتشابه إلى حد ما في المفهوم ، والناس تهيئة مقدم / المراقب المالي بشكل مختلف اعتمادا على الذوق.
    3. مقال كبير عن الاختلافات here . وأبرزها أن نموذج MVC يحتوي على نموذج يقوم بتحديث طريقة العرض.




glossary