خانه / OOP / مقایسه سه Pattern مهم مشتق شده از MV* بنام MVC و MVP و MVVM

مقایسه سه Pattern مهم مشتق شده از MV* بنام MVC و MVP و MVVM

مقایسه سه Pattern مهم مشتق شده از MV* بنام MVC و MVP و MVVM

MVC

MVC در واقع سرواژه ی Model-View-Controller می باشد. که سه مفهوم مهم در آن وجود دارد.

Model نیز وظیفه ی Model کردن Objectها (از جمله Student یا Teacher و …) را بر عهده دارد. Model را همچنین می توان ترکیبی از Data +State + Business logic هم دانست. Model ساده ترین بخش می باشد. و به هیچ Use Case یا Interaction یا حالت خاصی وابستگی ندارد.

View بخشی که به عنوان Interface عمل کرده و Interactionهای end-user از این طریق با برنامه به انجام خواهد رسید؛ به زبان ساده تر View در واقع Representation بیزینس دیتا می باشد. در MVC می توان کفت که View حالت “dumb” را بازی می کند؛ زیرا View به هیچ وجه از Model ای که باید نمایش دهد اطلاعی ندارد؛ و همچنین از اتفاقاتی که پس از click شدن یک دکمه قرار است اتفاق بیافتد.

Controller در این Pattern وظیفه ی Orchestration را بر عهده دارد. Controller را معولا بخش Glue می دانند که باعث میشود که یک بخش های مختلف تشکیل دهنده ی یک Application به هم متصل شوند. بدین معنی که Controller در خواست ها را دریافت و پس از انجام عملیاتی از جمله مثلا گرفتن لیستی از دانشجویان(تعامل با Model) این لیست را به View جهت نمایش به کاربر می فرستد. پس در واقع Controller هم واسطی است میان Model و View و هم بسته درخواست دریافت شده، مشخص می کند که چه Model و چه کنترلی جهت نمایش پاسخ انتخاب شود.

در MVC ما با چند Concern مهم درباره ی Controller سرو کار داریم.

  1. Testability: با توجه به اینکه Controller به View بسیار وابسته است؛ Test نمودن Controller با مشکل و سختی همراه خواهد بود.در MVC ما با چند Concern مهم درباره ی Controller سرو کار داریم.
  2. Modularity & Flexibility: مجدد به دلیل tight coupling با View داشتن این دو ویژگی پس از مدتی با مشکل مواجه خواهد شد. مثلا فرض کنید شما نیاز به تغییر دادن در View خود داشته باشید؛ جهت اعمال این تغییر نیاز خواهید داشت که Controller را نیز تغییر دهید.
  3. Maintenance: پس از مدتی معمولا کدهای بیشتر و بیشتری و Business logic بیشتری به Controller افزوده شده و باعث می شود که Maintain کردن آن به سختی و مشکل فراوان همراه شود.

MVP

MVP نیز acronym هست برای عبارت Model-View-Presenter. در اینجا Controller با Presenter جایگزین شده است. در MVP سعی شده است که interaction میان view و data که در مدل MVC امکان نداشت؛ نیز قابل اعمال باشد. در اینجا Presenter هم با View و هم یا Model ارتباط دارد. Presenter ضمن اینکه قادر به دستکاری نمودن Model را دارد می تواند View را نیز Update کند. کاری که در MVC؛ Controller قادر به انجام آن نبود. در MVC فقط Model مورد نیاز View جهت نمایش آن به کاربر را در اخیار View قرار می دهد.

دو نوع مختلف و متفاوت از پیاده سازی MVP وجود دارد:

  1. Passive View: در این رویکرد View هیچ اطلاعی از Model ندارد؛ و Presenter وظیفه Update کردن Model جهت نمایش در View را بر عهده خواهد داشت. در این استراتژی View و Model کاملا از یکدیگر مستقل و جدا هستند و هیچ تعاملی میان آنها وجود ندارد. Model ممکن است eventای raise کند؛ اما در اینجا Subscriber این event خود Presenter خواهد بود و Presenter وظیفه ی Update نمودن View را بر عهده خواهد داشت. در اینجا View همانطور که گفته شد هیچ bind مستقیمی ندارد؛ و در عوض هر Property در View شامل Setterای هست که توسط Presenter بهنگام نیاز پر خواهد شد. مهمترین مزیت این روش Testabilityبالای آن و clean separation ایست که میان View و Model ایجاد می کند.
  2. Supervising Controller؛ بر خلاف استراتژی قبل در این رویکرد View کاملا و مستقیما با Model در تعامل است و عملیات bind شدن Model درون View بدون دخالت Presenter شدن قابل انجام است. اما در این حالت Presenter هنوز وظیفه ی Update کردن Model را برعهده دارد.

یکی از موارد مهمی که در MVP بدنبال آن هستیم testability بیشتر Business Logic با mock نمودن view می باشد. خوب همانطور که قابل مشاهده است؛ این مورد با Passive View راحت تر و بهتر حاصل خواهد شد.

در صورتی که با user interface های بیشتر و پیچیده تر و تعاملات بیشتر با کاربران سروکار داریم در این جالت MVP بر MVC ارجحیت بیشتری خواهد داشت.

همچنین در صورتی که نیاز به داشتن automated unit test بر روی لایه view خود داشته باشید؛ این مورد با MVP نسبت به MVC بسیار بهتر و راحت تر حاصل خواهد شد.

یکی از تفاوت های مهم دیگر MVC و MVP نیز بدین صورت است که همانطور که بالا اشاره شد؛ در MVC وظیفه ی تعیین View جهت نمایش بر عهده ی Controller می باشد. و این در حالی است که در MVP عکس این قضیه صادق است؛ و route ها به سمت View می روند. در واقع action هایی که در View در هر دو الگوی MVC و MVP وجود دارد؛ یکسان می باشند؛ با این تفاوت که این action ها در MVC به Controller و در MVP به View اشاره می کنند و سپس توسط View به Presenter مربوط delegate خواهد شد.

MVVM

هسته ی اصلی این الگو از الگویی بنام Presentation Model یا  Application Model  که توسط آقای فاولر معرفی شد؛ گرفته شده است. در این الگو طبق تعریف آقای فاولر Presenter وجود ندارد. و View مستقیما به Presentation Model بایند می شود

The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.

To do this the Presentation Model will have data fields for all the dynamic information of the view. This won’t just include the contents of controls, but also things like whether or not they are enabled. In general, the Presentation Model does not need to hold all of this control state (which would be lot) but any state that may change during the interaction of the user. So if a field is always enabled, there won’t be extra data for its state in the Presentation Model.

 

Since the Presentation Model contains data that the view needs to display the controls you need to synchronize the Presentation Model with the view. This synchronization usually needs to be tighter than synchronization with the domain – screen synchronization is not sufficient; you’ll need field or key synchronization.

 

MVVM سپس با تاکید بیشتر بر Data Binding معرفی شد. این الگو همانند دو الگوی قبل سرواژه ی عبارت Model-View-ViewModel می باشد.

Model دقیقا همان نقشی را بازی می کند که بالاتر در الگوی MVC اشاره شد.

View در اینجا به یکسری object های observable بایند خواهد شد. این لایه همچنین می تواند اقدام به raise نمودن event هایی به ازای interaction ها end user نمایند. این event ها معمولا به action هایی که درون ViewModel تعریف و پیاده سازی شده اند؛ bind می باشند. هم چنین خاصیت observable بودن object های bind شده به View در اینجا این خاصیت را می دهد؛ که در صورت تغییر و بروز رسانی object ها این تغییرات در همان لحظه به درون View نیز منعکس شود.

ViewModel
ViewModel در واقع از یکطرف به عنوان یک wrapper بر روی Model عمل کرده و خاصیت observable بودن را به Model می دهد. و همچنین این امکان را برای View مهیا  می کند که در صورت نیاز بتواند event هایی را به action هایی که درون ViewModel تعریف شده اند raise نماید. یک نکته ی مهم که در اینجا باید به آن اشاره کرد برخلاف دو الگوی قبلی هر چند در اینجا ViewModel کاملا از View بی اطلاع است؛ View اما از ViewModel آگاه و با خبر است. نکته ی دیگر اینکه در این الگو بر خلاف دو الگوی قبلی View کاملا بصورت active عمل کرده و دارای event و data binding است. البته View در اینجا بهیپوجه state را نگه داری نمی کند. و این بر عهده ی ViewModel می باشد که متدهای و کامندهایی را جهت مدیریت state های برنامه expose کند.

View و ViewModel در این الگو از طریق method و properties و event ها در تعامل هستند. یکی از هدف های مهم در این الگوی sync نمودن هرچه سریعتر تغییرات به درون view می باشد. و bi-directional و two-way binding دو روشی هستند که جهت اعمال تغییرات به درون View مورد استفاده قرار می گیرند.

نتیجه گیری:

خوب همانطور که می توان انتظار داشت؛ MVP و MVVM هر دو نسبت به MVC جهت پیاده سازی یک ساختار ماژولار بهتر عمل می کنند؛ هر چند که می توان بوضوح مشاهده نمود که پیاده سازی هر دوی این الگوها در مقایسه با MVC مشکل تر خواهد بود.
برای برنامه ای به تعاملات کمتر و ساده تر MVC بهترین گزینه می تواند باشد؛ اما الگویی مثل MVVM می تواند جهت ایجاد و توسعه برنامه ای که نیازمند reactive model های بیشتر و متنوع تری جهت تعامل با کاربر باشد بوضوح بهتر و مناسبتر می باشد.

 

 

درباره ی masoud@admin

همچنین ببینید

Service Registration in Microservice

Service Registry در پست قبلی در باره ی یکی از جنبه های مهم معماری های …

ASP NET API Pipeline Part 2

1-بخش اول 2- بخش دوم —————————————————————————————– در بخش اول  بصورت مفصل به بررسی مفهوم Message Handlerها …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن