مزایای استفاده از الگوی M-V-VM

• جدا سازی لایه ها از یکدیگر: به این صورت تغییرات صورت گرفته در هر کدام از لایه ها به علت عدم تنیدگی در دیگری، با سهولت بیشتری صورت خواهد گرفت و نگهداری برنامه را در دراز مدت ساده تر خواهد کرد.
• امکان فعالیت تیمی بهتر : با توجه به جداسازی لایه ها، طراح رابط کاربر و برنام ه نویس ها همزمان می توانند کارهای خویش را انجام دهند (شکل 6).
• تهیه آزمون های واحد : همیشه تهیه ی آزمون واحد برای UI و کدهای event driven کاری بسیار مشکل است. اما در اینجا ViewModel را به سادگی می توان با کمک آزمون های خودکار بررسی کرد و میزان کدهای View به حداقل ممکن می رسد.
• پشتیبانی بهتر از چندین View: با توجه به جدا سازی لای ههای مختلف برنامه، امکان تهیه برنامه هایی که به سادگی قابل تبدیل به WPF و یا Silverlight هستند را خواهید داشت. همچنین می توان برای مثال دو View مختلف را ارائه داد به صورتیکه از یک ViewModel استفاده م یکنند و تفاوت آن ها در نحوه ی نمایش و قالب بندی اطلاعات ارائه شده توسط ViewModel است، بدون اینکه نیازی به تکرار کدها در برنامه وجود داشته باشد. به این صورت تغییر و یا تعویض یک View بدون تغییری در کدهای برنامه میسر خواهد شد.
• سادگی استفاده از کنترل های WPF و Silverlight : کنترل های بصری WPF و Silverlight اساسا جهت کار با این الگو طراحی شد هاند و بسیاری از قابلیت های آن ها با کمک الگوی M-V-VM بهتر نمایان خواهند شد.
• Blendability : به قابلیت ایجاد و ویرایش داد ههای آزمایشی در زمان طراحی رابط کاربر در Expression Blend ( و یا حتی طراح Visual Studio ) جهت مشاهد هی بهتر و نزدیک به واقعیت View تولید شده گفته م یشود که توسط این الگو بهتر از پیش میسر خواهد شد.
  
  شکل شش - یکی از مزایای الگوی M-V-VM امکان کار همزمان طراح رابط کاربر برنامه و برنامه نویس ها در یک تیم است.

اصول کاری و بایدها و نبایدهای الگوی M-V-VM

بایدها و نبایدهای یک View

• وظیفه ی آن نگهداری حالات خود نیست. ViewModel است که این وظیف هرا به عهده م یگیرد.
• نباید در آن کدهایی که نیاز به آزمون واحد دارند، پیاده سازی شوند. در حالت کلی، کد نویسی در Code behind یک View منعی ندارد اما اگر برای مثال در View قسمتی جهت انتخاب نام یک کشور و سپس قسمتی دیگر جهت نمایش مناطق مختلف آن کشور وجود دارد این مورد نیاز به نوشتن آزمون واحد داشته و نباید در Code behind پیاده سازی شود.
• نباید در Code behind آن روال های رخداد گردان کلیک بر روی یک دکمه و مانند آن مشاهده شود.
• می تواند یک user control و یا Data Template باشد.
• View را تا حد امکان ساده نگه دارید، هر چند استفاده از Data Trigger، Value Converter و موارد دیگر منعی ندارند.
• اگر عنصری به سادگی، قابلیت bind نداشت برای آن attached property تدارک ببینید.
• تنها باید از اطلاعات ViewModel استفاده کرده و نباید به صورت مستقیم هیچگونه تعاملی با Model داشته باشد.
• مهم ترین هدف و وظیفه ی یک View باید قالب بندی، بازآرایی و همچنین نمایش بصری اطلاعات باشد.

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

بایدها و نبایدهای ViewModel

• وظیفه ی آن شکل دهی به اطلاعات، مرتب سازی آ نها و سپس ارائ هی این داده ها به View است. برای مثال Model اطلاعات تاریخ را به فرمی خام نگهداری می کند، ViewModel به آن ها فرمت قابل ارائه به کاربر را بخشیده و سپس View این اطلاعات نهایی را نمایش می دهد.
• هیچگونه ارجاعی از View نباید در آن وجود داشته باشد.
• تا حد ممکن قابلیت آزمون واحد پذیری آن را درنظر داشته باشید. برای مثال فراخوانی کلاسی از نوع Singleton در آن نباید وجود داشته باشد.
• نباید در آن اثری از کنترل های بصری View دیده شود. در غیر اینصورت علاوه بر مشکل شدن تهیه آزمو نهای واحد برای یک ViewModel، به محض تغییر View باید ViewModel ما نیز کلا تغییر کند. بنابراین ارجاعی از PresentationFramework در آن نباید وجود داشته باشد. به عبارت دیگر طراحی آن باید logical باشد و نه Visual .
• تغییرات را باید از طریق پیاده سازی INotifyPropertyChanged به View منعکس کند ( الگوی Observer).
• نوع خواص تعریف شده در آن باید محدود به یک ViewModel دیگر یا نوع های اصلی و پایه و یا مجموع های از آن ها باشد.
• یکی از مکان هایی که می توان در آن پیاده سازی تعیین اعتبار ورودی کاربر را انجام داد ViewModel مرتبط است؛ زیرا لایه ای است میان Model و View برنامه. همچنین در این لایه بسیاری از اعمال تبدیلی را جهت حذف تبدیل کننده های WPF و Silverlight نیز م یتوان مد نظر داشت.

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

بایدها و نبایدهای Model

• وظیفه ی آن مدیریت و ارائه ی اطلاعات به ViewModel است. مخزنی است از اطلاعات اما وظیفه ی آن دریافت اطلاعات از یک دیتابیس یا سرویس و یا تغییرات بر روی آن ها نیست. منطق تجاری باید از مدل مجزا شده و در کلا سهای دیگری نگهداری شود.
• نباید ارجاعی از View و یا ViewModel در آن وجود داشته باشد. برای مثال نباید در یک مدل ارجاعی به PresentationFramework و موارد دیگری که پیشتر از آ نها یاد شد، مشاهده شود.
• نباید در سایر لایه ها، نیازی به کلاس های دیگر برای کار با آن وجود داشته باشد. به بیان دیگر هر نوع عملیاتی که نیاز است بر روی داد هها صورت گیرد باید توسط این کلا سها انجام شده و سایر کلاس ها نباید به صورت مستقیم سر و کاری با بانک اطلاعاتی و ساختار آن و یا ذخیره یا بازیابی اطلاعات داشته باشند.
• زمانیکه نیاز به درخواست بازخورد از کاربر در آن وجود داشت باید از Events استفاده گردد.
• یک مدل می تواند با پیاده سازی IDataErrorInfo قسمتی از کار تعیین اعتبار داده ها را نیز به عهده بگیرد. به بیان دیگر تهیه ی مدلی که هیچگونه منطق تجاری را پیاده سازی نم یکند در اکثر مواقع میسر نیست و در این موارد بهتر است منطق تجاری اعمالی بر روی مدل، در کلاس های مجزایی نگه داری شوند.

مروری بر معایب الگوی M-V-VM

• با توجه به اینکه این الگو توسط تیم WPF ارائه شده است اما هنوز استاندارد سازی نشده و همچنین روش ها یا ابزارهای استاندارد و کاملا مشخصی نیز برای پیاده سازی آن ارائه نشده است. به همین جهت امروزه شاهد چندین Framework توسعه یافته توسط برنامه نویس های مختلف در این زمینه هستیم و هر روز نیز تعداد آ نها افزایش می یابد ( مانند Microsoft WPF Toolkit ، Onyx ، Prism ، Crack.net ، Caliburn ، MVVM Light Toolkit  و . . . ).
• مطابق نظر خالق این الگو ، John Gossman، الگوی M-V-VM برای برنام ههای کوچک شاید مناسب نباشد و پیچیدگ یهای بی جهتی را به آن ها تحمیل کند.

هر چند مورد اول ذکر شده را می توان نوعی مزیت بر شمرد. به این صورت افراد مختلف با توانایی های متفاوت می توانند Framework در خوری را بیابند.

و در پایان باید در نظر داشت که برای توسع هی هر محصولی باید از ابزار متناسب با آن بهره جست. برای مثال در توسعه و طراحی یک بازی نوشته شده با WPF یا Silverlight الگوی M-V-VM شاید انتخاب مناسبی نباشد اما در سیستم های مبتنی بر داده و فر مهای ورود اطلاعات، انتخاب اول به شمار م یرود.

شکل نه – تصویری نمادین از قابلیت تغییر و نگهداری ساده تر برنامه های مبتنی بر MVVM