MVC vs MVP vs MVVM: شرح أنماط هندسة أندرويد الشائعة
نشرت: 2022-05-27أثناء العمل كمطور ، يجب أن تكون قد سمعت عن الأنماط المعمارية. في عالم Android ، أكثرها شهرة هي MVC و MVP و MVVM . ربما تعرف خصائصها ، لكن هل تعرف الاختلافات ومتى تستخدمها؟
إذا سألت نفسك هذه الأسئلة ، فهذا المقال لك.
MVC - وحدة تحكم عرض النماذج
Model-View-Controller (MVC) هو نمط معماري يساعد في تنظيم هيكل تطبيقنا. يقسم مسؤولياته إلى ثلاث طبقات: النموذج والعرض والمراقب.
هل تحتاج إلى خبراء Android؟
اعمل معنا!- النموذج - طبقة البيانات ، المسؤولة عن إدارة منطق الأعمال ودعم واجهة برمجة تطبيقات الشبكة أو قاعدة البيانات. يعمل النموذج مع مصادر البيانات البعيدة والمحلية للحصول على البيانات وحفظها. هذا هو المكان الذي يتم فيه معالجة منطق الأعمال.
- طريقة العرض - طبقة واجهة المستخدم المسؤولة عن تصور البيانات من النموذج إلى المستخدم. يدير طريقة تقديم البيانات ، بما في ذلك الواجهة الرسومية.
- المتحكم - طبقة منطقية تدمج طبقات العرض والنموذج. تتمثل مهمة المتحكم في تولي إدخالات المستخدم وتحديد ما يجب فعله بها.
يمكنك أن ترى بسرعة كيف تتواصل المكونات الفردية في الرسم أدناه:

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

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

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

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

إذا كان نمط MVP يعني أن المقدم كان يخبر العرض مباشرة بما يجب عرضه ، فإن MVVM ViewModel يعرض تدفقات الأحداث التي يمكن ربط طرق العرض بها. لم يعد ViewModel بحاجة إلى تخزين مرجع إلى طريقة العرض كما فعلت مع المقدم. هذا يعني أيضًا أن جميع الواجهات التي يتطلبها نمط MVP أصبحت غير ضرورية الآن.
تقوم طرق العرض أيضًا بإخطار ViewModel بالإجراءات المختلفة ، كما هو موضح في الرسم أعلاه. لذلك ، يدعم نمط MVVM ربط البيانات ثنائي الاتجاه بين العرض و ViewModel. يحتوي العرض على مرجع إلى ViewModel ، لكن لا يحتوي ViewModel على معلومات حول طريقة العرض.
مزايا
- يعد اختبار الوحدة أكثر وضوحًا لأنك لست مدمنًا على طريقة العرض. يكفي التحقق من أن المتغيرات التي يمكن ملاحظتها يتم وضعها بشكل صحيح مع تغير النموذج عند الاختبار.
- تعد ViewModels أكثر ملاءمة لاختبار الوحدة لأنها تعرض الحالة ببساطة ، وبالتالي يمكن اختبارها بشكل مستقل دون اختبار كيفية استهلاك البيانات. باختصار ، لا يوجد اعتماد على وجهة النظر.
- يحتوي العرض فقط على مرجع إلى ViewModel ، وليس العكس. هذا يحل مشكلة الاقتران الضيق. يمكن أن يشير عرض واحد إلى نماذج ViewModels متعددة.
- حتى بالنسبة إلى طرق العرض المعقدة ، يمكن أن يكون لدينا نماذج طرق عرض مختلفة في نفس التسلسل الهرمي.
سلبيات
- تعد إدارة نماذج ViewModels وحالتها في واجهة المستخدم المعقدة تحديًا للمبتدئين في بعض الأحيان.
ملخص
يجمع MVVM بين المزايا التي يوفرها MVP أثناء استخدام مزايا ربط البيانات والاتصال المستند إلى الحدث. والنتيجة هي نمط يتحكم فيه النموذج في أكبر عدد ممكن من العمليات ، مع فصل الكود العالي وقابلية الاختبار.
MVC مقابل MVP و MVVM: المقارنة
MVC | أفضل لاعب | MVVM | |
---|---|---|---|
اعمال صيانة | من الصعب صيانتها | سهل الصيانة | سهل الصيانة |
صعوبة | سهل التعلم | سهل التعلم | أكثر صعوبة في التعلم بسبب الوظائف الإضافية |
نوع العلاقة | علاقة أطراف برأس بين وحدة التحكم والعرض | علاقة رأس برأس بين المقدم والعرض | علاقة رأس برأس بين طريقة العرض و ViewModel |
وحدة التجارب | بسبب اقتران ضيق ، يصعب اختبار وحدة MVC | أداء جيد | اداء ممتاز |
نقطة الدخول | مراقب | رأي | رأي |
مراجع | لا تحتوي طريقة العرض على إشارة إلى وحدة التحكم | العرض له إشارة إلى المقدم | طريقة العرض لديها إشارة إلى نموذج العرض |
MVC مقابل MVP و MVVM: ملخص
كل من نمط MVP ونمط MVVM أفضل بكثير من نمط MVC. الطريقة التي تختارها تعتمد حقًا على تفضيلاتك. ومع ذلك ، آمل أن تكون هذه المقالة قد أوضحت لك الاختلافات الرئيسية بينهما وستجعل الاختيار أسهل.
البحث عن بديل؟
اختر منصة مشتركة!فهرس:
- Cervone، S. (2017) Model-View-Presenter: إرشادات Android.
- Dang، AT (2020) MVC ضد MVP و MVVM.
- مونتينيسكو ، ف. (2016) أنماط هندسة أندرويد ، الجزء الأول: نموذج-عرض-متحكم.
- مونتينيسكو ، ف. (2016) أنماط هندسة Android ، الجزء الثاني: نموذج-عرض-مقدم.
- مونتينيسكو ، ف. (2016) أنماط هندسة Android ، الجزء الثالث: نموذج عرض وعرض نموذج.