Model View Presenter - قسمت دوم
در قسمت اول، کلیاتی از الگوی MVP گفته شد. گفته شد که در الگوی MVP با تفکیک شدن کد Business از UI قابلیت تست به خوبی پوشش داده می شود. در این قسمت سعی می کنم جزییات بیشتری از این الگوی UI را شرح دهم.
در یک برنامه کاربردی در یک صفحه یا فرم، اطلاعات Domain در قالب کنترل هایی به کاربر نشان داده می شوند.کاربر می تواند اطلاعات را تغییر دهد و نتیجه را مشاهده کند. کد زدن این تعاملات در Code Behind صفحات(فرمها) و نداشتن یک استراتژی مناسب باعث بروز مشکلاتی از قبیل پیچیدگی، دشواری نگهداری و دشواری در تست می شود.مشکل بزرگتر استفاده مجدد از این کدها در صفحه(فرم) دیگری است که به همان رفتارها نیاز دارد.
انتظار می رود الگوهای UI این مشکلات را برای ما حل کنند به این شکل که حجم بیشتری از کد را بتوان به شکل مکانیزه تست کرد، کدها را بتوان در بین صفحات(فرمها) به اشتراک گذاشت و نهایتاً بتوان UI Logic را به صورت کاملاً مشخص از Business Logic جدا کرد تا خوانایی و قابلیت نگهداری آن بالا برود.
در MVP دو مسئولیت نمایش بصری اطلاعات و هندل کردن رویدادها در دو کلاس View و Presenter تفکیک شده اند.View کنترل های صفحه را مدیریت می کند و رویدادها را به Presenter منتقل می کند.Presenter که شامل UI Logic است، نسبت به رودادها واکنش نشان می دهد و وضعیت View را اداره می کند.نکته مهم این که Presenter به اینترفیسی از View دسترسی دارد و از کلاس Concrete ی View هیچ اطلاعی ندارد و این اصل، قابلیت تست را در این الگو بالا می برد.
شکل زیر به خوبی مفهوم MVP را می رساند:
MVP دارای سه جزء اصلی به شرح زیر است:
-
Model: مدل آبجکت سطح Domain است که دیتای Application را نگه می دارد و متدهایی را برای دسترسی به این دیتا فراهم می کند.یک مدل نباید هیچ ارتباطی با User Interface داشته باشد.این محدودیت این امکان را فراهم می کند که در شرایطی که لازم باشد UI به طور کلی عوض شود، کدها به راحتی قابل استفاده مجدد باشند. در واقع Model هیچ دانشی از وجود View و Presenter ندارد.
-
View: پنجره ای است شامل مجموعه ای از کنترل های UI، که وظیفه اش نمایش/گرفتن اطلاعات مدل به/از کاربر است.این کار با ارتباط غیر مستقیم View و Model انجام می شود، که در این ارتباط غیر مستقیم، View یک Observer بر روی Model است. بسته به قالب UI، این پنجره می تواند User Control، WindowsForm، WebForm و یا هر چیز دیگری باشد.
-
Presenter: همانطوری که گفته شدView وظیفه دارد تا خروجی اطلاعات Model را به کاربر نشان دهد یا اطلاعات ورودی کاربر را بگیرد. وظیفه Presenter نیز که به عنوان قطعه سوم این پازل سه تایی است، آماده سازی و به عمل آوردن اطلاعات مدل است.رفتار کاربر(از قبیل کلیک کردن، تایپ کردن و …) نیز که توسط View گرفته می شود به Presenter تحویل داده می شود. با این تعاریف Presenter اجازه دارد در مورد هر دوی Model و View بداند تا بتواند نقش واسطه و میانجی گری را بین این دو برقرار کند.
نحوه برقراری ارتباط بین Model و View، شاید دغدغه ای بوده که باعث شده است الگوی MVP به دو شکل Passive View و Supervising Controller پیاده سازی شود.شکل زیر به خوبی بیانگر این تفاوت هاست:
Passive View دارای محدودیت بیشتری است، در مقابل Supervising Controller انعطاف پذیری بیشتری در UI های پیچیده دارد.باید به این نکته توجه کرد که این انعطاف پذیری در قبال از دست دادن بخش کمی از قابلیت تست بدست می آید.با این توضیحات، برای سیستم های که دارای UI پیچیده و متشکل از تعداد زیادی Grid است، الگوی Supervising Controller پیشنهاد می شود، در غیر این صورت Passive View انتخاب بسیار مناسبی است.
برای کسانی که با الگوی MVC کار کرده و آشنایی دارند، شاید این مطلب جالب باشد که MVP بر اساس و پایه MVC بنا شده است با این تفاوت که در آن کنترل کمتری روی View و Responsibility بیشتری روی Presenter است.می گویند که MVP فرزند و خلف MVC است.
