M-V-VM چیست؟

M-V-VM یا Model-View-ViewModel یکی از الگوهای محبوب طراحی رابط کاربر در WPF و Silverlight می باشد که توسط Jhon Gossman از تیم WPF ایجاد شده است و قدرت خود را مدیون توانمندی های BINGING پیشرفته WPF و SILVERLIGHT است. به کمک آن می توان VIEW (یا همان قسمتی از برنامه که کاربر با آن سر و کار دارد) را از کدهای مرتبط با داده ها و منطق برنامه مجزا ساخت. به این صورت در یک تیم افرادی می توانند بر روی VIEW در EXPRESSION BLEND کار کرده و همزمان تعدادی دیگر در VS.NET مشغول تهیه قسمت ViewModel ها باشند.

شکل یک - نمایی از قرارگیری و نحوه تعامل لایه های مختلف در یک برنامه با الگوی M-V-VM

روش متداول آموزش و کار با WPF و Silverlight همانند روزهای WinForms یا VB6 است. تمام کنترل های بصری نامگذاری می شوند. سپس رویدادها به صورت مستقیم تعریف شده و در Code behind صفحه« منطق مرتبط با آن پیاده سازی می شود( یعنی در کدهای View  ارجاعات مستقیمی به Model خواهیم داشت). همچنین پیاده سازی به همراه استفاده مستقیم از نام اشیاء و کنترل هایی است که در View تعریف شد هاند. حاصل این عملیات متداول، گره خوردگی کدهای صفحه با View است که امکان نوشتن آزمون های واحد آن را به صفر می رساند. همچنین از امکانات پیشرفته ی WPF و Silverlight مانند انقیاد دوطرفه (Tow way binding) و بسیاری موارد دیگر نیز استفاده نخواهد شد. به علاوه با توجه به استفاده ی مستقیم از نام کنترل های بصری در code behind ، تغییر یا جایگزینی یک کنترل نیاز به تغییرات وسیعی در کدهای ما خواهد داشت. برای رفع این مشکلات، الگوی M-V-VM ارائه شده است که توسط خود مایکروسافت جهت بهره گیری از تمامی امکانات WPF و Silverlight ابداع گردیده و در تهیه ی محصولات مهم Microsoft Expression Blend نیز بکار گرفته شده است.

آشنایی با اجزای مختلف الگوی M-V-VM

به صورت خلاصه هدف اصلی الگوی M-V-VM جداسازی مسایل مرتبط با رابط کاربر (View) از اشیاء تجاری و حالات آنها (View Models) و همچنین از لایه داده ها و دسترسی به داده ها (Model) است.

شکل دو - نمایی از نحوه تعاریف و تعاملات اجزای مختلف در الگوی M-V-VM

• Model - گروهی از موجودیت ها می باشند که ارائه خواهند شد. برای مثال کلاس مشتری به همراه خواص نام و شماره شناسایی او. مدل های برنامه از اینکه اطلاعات آ نها از کجا تهیه خواهند شد یا چگونه به کاربر نمایش داده می شوند اطلاعاتی ندارند. یک مدل خوب نباید نیازی به ارجاعاتی به PresentationFramework.dll ، System.Windows.Forms ، PresentationCore و امثال آن ها داشته باشد. همچنین باید بتوان به سادگی از آن حتی در یک برنامه ی کنسول نیز استفاده کرد. البته باید در نظر داشت که پیاده سازی های متفاوتی از مدل یا سایر قسم تهای این الگو مشاهده می شود و الزامی به رعایت حتمی تک تک این موارد نیست.
• View - همان کدهای Xaml ایی هستند که جهت نمایش رابط گرافیکی تهیه می شوند و نه بیشتر. View می تواند شامل کنترل های بصری، پویانمایی و غیره باشد به همراه تعاریف binding به اطلاعات؛ اما با این شرط که View نمی داند این اطلاعات در کجا قرار دارند و یا چگونه تهیه خواهند شد. عموماً از user control ها و یا Data Template ها برای تهیه View استفاده می کنند. یکی از اهداف الگوی M-V-VM داشتن View هایی است که دارای Conde behind نیستند و هیچ منطقی را پیاده سازی نمی کنند.
• View Model - مدلی آینه ای از View است به شکل یک کلاس (Model  of a View) که توسط آن می توان برای کل View به جای تعامل مستقیم با آن، آزمون واحد (Unit test) تهیه نمود. View Model محل اتصال View  به دنیای خارج است (به آن meta-view نیز گفته می شود). توسط این کلاس که اطلاعات binding و Command در اختیار View قرار می گیرد. View Model بیانگر حالت و رفتار Viiew (های) متناظر آن است.

شکل سه - نحوه ی ارتباط بین اجزای مختلف الگویM-V-VM

در اینجاهرخاصیتیکهقراراستدرbinding شرکتداشتهباشدبایداینترفیسINotifyPropertyChangedراپیادهسازینماید. دراینالگوحرکاتوتعاملاتکاربرمانندکلیکبرروییکدکمه بهصورت Commands ارائهمیگردند. درزمانایجاد  ViewModel تنهاساختارView استکهبایدمدنظرقرارگیردونهظاهرکلیآن. همچنینجهتبالابردنقابلیتآزمونهایواحدآناینکلاسنبایدهیچگونهارجاعیرابهکنترلهایبصریداشتهباشد.
درالگوی  M-V-VM همانطورکهدرشکل3نیزمشخصشدهاست، View تنهااز ViewModel اطلاعاتلازمرادریافتمیکند و  هیچگونهاطلاعاتیاز Model ندارد.ViewModel اطلاعاتموردنیاز خودراازModel تهیهمیکند امااطلاعاتیاز View ندارد و Model تنهاخودشرامی شناسد.
در شکل 4 ارتباط مستقیم View با Model نیز نمایش داده شده است. گاهی از اوقات اگر ViewModel شما هیچگونه منطقی را پیاده سازی نم یکند، لزومی هم به ایجاد آن نیست؛ در غیر اینصورت حتما کار وفق دادن اطلاعات Model با View را از طریق ViewModel پیاده سازی نمائید.
View به خواص تعریف شده در ViewModel بایند (مقید) خواهد شد (توسط DataContext هر View). با توجه به پیاده سازی اینترفیس INotifyPropertyChanged، هر تغییری در خواص ViewModel بدون نیاز به کد نویسی، در UI و View برنامه منعکس می گردد. بنابراین تغییرات بر روی داده ها تنها در ViewModel باید صورت گیرد و نه در View .

شکل چهار – نمایی از نحوه ی ارتباط بین ViewModel و Viewدر الگوی MVVM.
به صورت خلاصه نحوه ی تعامل بین View و ViewModel به شکل زیر است:

• ارتباطات بین View و ViewModel از طریق data-binding  فراخوانی متدها، خواص، رخ دادها، و پیغام ها است.
• ViewModel علاوه بر ارائه ی خواص ضروری Model به View می تواند یک سری حالات و یا Commands را نیز در اختیار View قرار دهد.
• رخ دادهای یک View از طریق Commands به ViewModel منتقل م یشوند.
• خواص ارائ هی شده ی ViewModel به View از طریق binding دو طرفه به روز رسانی می شوند.

و نحوه ی تعامل بین ViewModel و Model به صورت زیر است:

• ViewModel می تواند تمام خواص یا تعدادی از خواص مفید Model را جهت data-binding در اختیار View قرار دهد.
• ViewModel می تواند شامل اینترفیس هایی به سرویس ها یا تنظیماتی خاص جهت دریافت و اعمال تغییرات بر روی اطلاعاتی باشد که به View ارائه می دهد.

شکل بعد روابط اجزای سه معماری *MV را بیان می کند و با توجه به آن کاملا مشخص است که یکی از اهداف اصلی الگوی MVVM، سهولت هرچه بیشتر انجام آزمو نهای واحد است و از هر دو معماری MVP و MVC قابلیت آزمایش پذیری بهتری را ارائه می دهد.

شکل پنج – مقایسه ای از روابط اجزای مختلف سه معماری متفاوت *MV
در قسمت دوم به مزایای استفاده از الگوی M-V-VM را تشریح خواهیم کرد.