معماری های نرم افزار MVVM , MVP

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

برای مطالعه پست الگوی معماری نرم افزار و الگوی معماری فریم ورک Laravel می توانید از این لینک استفاده کنید.

معماری MVVM

مدل - نما - مدل نما (Model – view – Viewmodel) یک الگوی معماری نرم افزاری است که تفکیک توسعه رابط کاربری گرافیکی (view)، اعم از زبان علامت گذاری یا کد GUI را تسهیل می کند. و به توسعه منطق تجاری یا پشتیبان منطق بک اند (model) به طوری که view به هیچ بستر model خاصی وابسته نباشد، می پردازد.

مدل نمای (Viewmodel) معماری MVVM ، مبدل مقادیر است . به این معنی که وظیفه View model ، تبدیل اشیا(data objects) از مدل است به گونه ای که object ها به راحتی مدیریت و ارائه شوند. به این خاطر، View model بیشتر از View، حالت model بودن دارد و بیشتر (نه همه ی) منطق نمایش view را کنترل می کند. View model ممکن است یک الگوی میانجی را پیاده سازی کند ، دسترسی به منطق بک اند، در مجموعه موارد استفاده پشتیبانی شده توسط view را سازماندهی کند.

معماری MVVM نوعی الگوی طراحی مدل ارائه Martin Fowler است. این معماری توسط معماران مایکروسافت Ken Cooper و Ted Peters به طور خاص برای ساده سازی برنامه نویسی مبتنی بر رابط های کاربر ابداع شده است. این الگو در (Windows Presentation Foundation (WPF (سیستم گرافیکی دات نت مایکروسافت) و Silverlight (مشتق برنامه اینترنت WPF) گنجانیده شد. John Gossman ، یکی از معماران WPF و Silverlight مایکروسافت ، MVVM را در وبلاگ خود در سال 2005 منتشر کرد.

از Model – view – viewmodel به عنوان اتصال دهنده Model – View نیز یاد می شود ، خصوصاً در پیاده سازی هایی که شامل پلتفرم NET. نیستند. ZK (یک چارچوب برنامه وب نوشته شده به زبان جاوا) و KnockoutJS (یک کتابخانه جاوا اسکریپت) از MVVM استفاده می کنند.

اجزای الگوی MVVM

1) مدل (Model)

مدل یا به یک مدل دامنه ، که نمایانگر محتوای حالت واقعی است (یک رویکرد شی گرا) ، یا به لایه دسترسی به داده ، که نمایانگر محتوا است (یک رویکرد داده محور) اشاره دارد.

2) نما (View)

همانند الگوهای مدل-نما-کنترل کننده (MVC) و مدل-نما-ارائه دهنده (MVP) ، نمای ساختار ، طرح و شکل ظاهری است که کاربر در صفحه میبیند. view نمایشی از مدل را نشان می دهد و تعامل کاربر را با view (کلیک ها ، صفحه کلید ، حرکات و غیره) دریافت می کند. و مدیریت این موارد را از طریق اتصال داده (ویژگی ها ، تماس های رویداد و غیره) به مدل نمایش می دهد. که برای پیوند دادن view و view model تعریف شده است.

در مورد الگوی MVC در پست قبل صحبت کردم. و الگوی MVP در ادامه توضیح داده خواهد شد.

3) مدل نما (View model)

مدل نما (View model) انتزاعی از نمای خصوصیات عمومی و دستورات است. به جای کنترل کننده الگوی MVC یا ارائه دهنده الگوی MVVM ، MVP دارای یک اتصال دهنده است که ارتباط بین view و خصوصیات محدود شده آن را در View model به صورت خودکار انجام می دهد. View model به عنوان حالت داده های موجود در مدل توصیف شده است.

تفاوت اصلی بین View model و ارائه دهنده در الگوی MVP این است که ارائه دهنده به یک View مراجعه می کند ، در حالی که View model اینگونه نیست. در عوض ، یک view مستقیماً برای ارسال و دریافت به روزرسانی ها به خصوصیات موجود در View model متصل می شود. برای عملکرد کارآمد ، این امر به یک فن آوری اتصال نیاز دارد.

4) اتصال دهنده (Binder)

داده های اعلامی و الزام آور دستور در الگوی MVVM ضمنی است. در پشته راه حل مایکروسافت ، Binder یک زبان نشانه گذاری به نام XAML است. binder ، توسعه دهنده را از نوشتن منطق boilerplate برای همگام سازی view model و نview ، آزاد می کند. هنگامی که خارج از پشته مایکروسافت اجرا می شود ، وجود یک فناوری اتصال داده های اعلامی همان چیزی است که این الگو را ممکن می کند و بدون binder ، معمولاً از MVP یا MVC استفاده می شود و باید boilerplate بیشتری بنویسید (یا آنرا با ابزار دیگری تولید کنید).

مزایای الگوی MVVM

الگوی MVVM برای استفاده از توابع اتصال داده در WPF (بنیاد ارائه Windows) طراحی شده است تا با حذف تقریباً همه کد (GUI (code-behind از لایه view ، جداسازی توسعه لایه view از بقیه الگو را تسهیل کند. به جای اینکه به توسعه دهندگان UX برای نوشتن کد GUI نیاز داشته باشند ، آنها می توانند از زبان نشانه گذاری (به عنوان مثال XAML) استفاده کنند و اتصال داده ها را به view model ایجاد کنند ، که توسط توسعه دهندگان برنامه نوشته شده و نگهداری می شود. تفکیک نقش به طراحان تعاملی اجازه می دهد تا بیش از برنامه ریزی منطق کسب و کار ، بر نیازهای UX تمرکز کنند. بنابراین لایه های یک برنامه می تواند در چندین جریان کاری برای بهره وری بالاتر توسعه یابد. حتی وقتی یک توسعه دهنده واحد روی کل کد پروژه کار می کند، تفکیک مناسب view از model بازده بیشتری دارد ، زیرا رابط کاربری معمولاً بر اساس بازخورد کاربر ، به طور مکرر و در اواخر چرخه تغییر می کند.

الگوی MVVM تلاش می کند تا هر دو مزیت جداسازی توسعه عملکرد ارائه شده توسط MVC را بدست آورد ، در حالی که از مزایای اتصال داده ها و فریم ورک با اتصال داده ها به نزدیکترین مدل کاربرد خالص استفاده کند. برای صحت سنجی داده های ورودی ، از binder ، view model و ویژگی های بررسی داده لایه های تجاری استفاده می شود. نتیجه این است که مدل و فریم ورک تا حد امکان عملیات را هدایت می کند ، منطق برنامه را که مستقیماً view را دستکاری می کند از بین می برد یا به حداقل می رساند (به عنوان مثال code-behind).

معایب الگوی MVVM

انتقادی از این الگو از جانب John Gossman ، خالق MVVM ارائه شده است كه سربار اجرای MVVM برای عملیات ساده رابط كاربری "بیش از حد" است. وی می گوید برای کاربردهای بزرگتر ، تعمیم View Model دشوارتر می شود. علاوه بر این ، او نشان می دهد که اتصال داده در برنامه های بسیار بزرگ می تواند باعث مصرف قابل توجه حافظه شود.

پیاده سازی ها

.NET frameworks

• Prism Library
• Caliburn / Caliburn.Micro
• DevExpress MVVM
• DotVVM open source project
• MVVMLight Toolkit
• ReactiveUI
• Mugen MVVM Toolkit
• Uno Framework - Open Source
• Rascl
• MvvmCross
• FreshMvvm

JavaScript frameworks

• Angular
• Reactjs
• Aurelia
• Durandal
• Ember.js
• Ext JS
• Knockout.js
• Omi.js
• Oracle JET
• Svelte
• Vue.js

Android apps

مراجع : wikipedia.org

معماری MVP

مدل-نما-ارائه دهنده (Model–view–presenter) مشتق شده از الگوی معماری مدل-نما-کنترل کننده (MVC) است و بیشتر برای ساخت رابط کاربر استفاده می شود. در MVP ، ارائه دهنده، عملکرد "مرد میانه" را بر عهده می گیرد. و تمام منطق ارائه به سمت presenter رانده می شود.

الگوی نرم افزاری MVP از اوایل دهه 1990 در Taligent ، سرمایه گذاری مشترک اپل ، IBM و Hewlett-Packard ایجاد شد. MVP مدل اصلی برنامه نویسی برای توسعه برنامه های Taligent در محیط CommonPoint مبتنی بر C ++ است. بعداً این الگو توسط Taligent به جاوا منتقل شد و در مقاله ای توسط Taligent CTO Mike Potel انتشار یافت.

پس از متوقف شدن فعالیت Taligent در سال 1998 ، Andy Bower و Blair McGlashan برای پایه ی چارچوب رابط کاربری Smalltalk از الگوی MVP اقتباس کردند. در سال 2006 ، مایکروسافت شروع به ادغام MVP در اسناد و مثالهای خود برای برنامه نویسی رابط کاربر در فریم ورک NET. کرد.

تکامل و انواع مختلف الگوی MVP ، از جمله رابطه MVP با سایر الگوهای طراحی مانند MVC ، به طور مفصل در مقاله ای توسط Martin Fowler و دیگری توسط Derek Greer مورد بحث قرار گرفته است.

اجزای الگوی MVP

الگوی MVP یک الگوی معماری رابط کاربری است که برای تسهیل آزمایش و بهبود در منطق ارائه طراحی شده است:

• مدل (Model) : مدل رابطی است که داده هایی را نشان می دهد که در رابط کاربری نمایش داده می شوند یا کاربر روی آن داده ها عملی انجام میدهد. لایه داده که مسئولیت رسیدگی به منطق تجارت و ارتباط با شبکه و لایه های پایگاه داده را دارد.
• نما (View) : یک رابط غیرفعال است که داده ها (model) را نمایش می دهد و دستورات کاربر (events) را به سمت ارائه دهنده (presenter) هدایت می کند تا بر اساس آن داده ها، عمل کند.
• ارائه دهنده (Presenter) : ارائه دهنده بر اساس Model و View عمل می کند. داده ها را از مخازن (Model) بازیابی می کند و آنها را برای نمایش، منظم می کند.

به طور معمول ، پیاده سازی View شی ارائه دهنده واقعی را ارائه می دهد و مرجعی را به خود ارائه می دهد. کد C # زیر یک سازنده View ساده را نشان می دهد ، جایی که ارائه دهنده دامنه اصلی رابط Domain Presenter را پیاده سازی می کند:

public class DomainView : IDomainView
{
    private IDomainPresenter _domainPresenter = null;

    /// <summary>Constructor.</summary>
    public DomainView()
    {
        _domainPresenter = new ConcreteDomainPresenter(this);
    }
}

درجه منطق مجاز View در پیاده سازی های مختلف متفاوت است. از یک سو ، View کاملاً منفعل است و همه عملیات تعامل را به presenter هدایت می کند. در این فرمول ، هنگامی که یک کاربر یک رویداد از View را راه اندازی می کند ، کاری جز فراخوانی روشی از presenter، که هیچ پارامتر و مقدار بازگشتی ندارد. سپس presenter، داده ها را از طریق روش هایی که توسط رابط View تعریف شده است ، بازیابی می کند. سرانجام ، presenter با استفاده از Model کار می کند و View را با نتیجه به روز می کند. سایر نسخه های MVP اجازه می دهد تا برخی از عمل هاd کلاس قادر به تعامل ، event یا دستور خاص ، باشد. این اغلب برای معماری های تحت وب مناسب تر است. View ، که در مرورگر مشتری اجرا می شود ، بهترین مکان برای مدیریت تعامل یا دستور خاص است.

از نظر لایه بندی ، کلاس presenter ممکن است متعلق به لایه برنامه در یک سیستم معماری چند لایه باشد ، اما همچنین می تواند به عنوان یک لایه ارائه دهنده، بین لایه برنامه و لایه رابط کاربر باشد.

پیاده سازی ها

1) .NET

محیط NET. مانند هر محیط توسعه دیگری از الگوی MVP پشتیبانی می کند. از همان Model و کلاس presenter می توان برای پشتیبانی از چندین رابط ، مانند یک برنامه وب ASP.NET ، یک برنامه Windows Forms یا یک برنامه Silverlight ، استفاده کرد. presenter اطلاعات را از طریق رابط قابل دسترسی از طریق واسطه (view) از / به view دریافت می کند.

علاوه بر اجرای دستی الگو ی MVP ، ممکن است از یک چارچوب model-view-presenter برای پشتیبانی از الگوی MVP به صورت خودکارتر استفاده شود.

2) Java

در یک برنامه جاوا (AWT / Swing / SWT) ، با اجازه دادن به کلاس رابط کاربر که یک رابط view را پیاده سازی کند ، می توان از الگوی MVP استفاده کرد.

فریم ورک های جاوا شامل موارد زیر است:

• JavaFX
• Echo2
• Google Web Toolkit
• JFace
• Swing
• Vaadin
• ZK

3)PHP

از آنجا که در محیط اجرای انعطاف پذیر PHP ، امکانات گسترده ای برای منطق برنامه وجود دارد. اجرای لایه Model بر روی برنامه، برنامه آخر باقی مانده است.

چارچوب های PHP شامل موارد زیر است:

• CodeIgniter
• Laravel
• Nette Framework

4)Kotlin

کاتلین و چارچوب های مبتنی بر آن مانند Kodein Framework ، بر سازگاری چند پلتفرم تمرکز دارند. هدف این است که به دلیل چارچوبی که برای سازگاری با هر سیستم عامل ایجاد شده است ، فقط یک بار بر منطق تجارت تمرکز کرده و آن را پیاده سازی کنیم.

مراجع : wikipedia.org

با توجه به توضیحات داده شده شاید برای شما سوال باشد که فرق بین معماری های MVVM و MVP و MVC در چیست؟

الگو های MVP و MVVM هر دو از مشتقات MVC هستند. تفاوت کلیدی بین MVC و مشتقات آن وابستگی هر لایه به لایه های دیگر و همچنین چگونگی محکم اتصال آنها به یکدیگر است.

در MVC ، نما(View) در بالای معماری ما قرار می گیرد و کنترلر در کنار آن است. مدل ها زیر کنترل کننده قرار می گیرند ، بنابراین View ما از کنترل کننده ها و کنترل کننده ها از مدل ها اطلاعات دارند. در اینجا ، view ما مستقیماً به مدل ها دسترسی دارند. اگرچه قرار دادن مدل کامل در معرض دید ، بسته به پیچیدگی برنامه ما ممکن است دارای هزینه های امنیتی و عملکردی باشد. MVVM سعی دارد از این مسائل جلوگیری کند.

در MVP ، نقش کنترل کننده با یک ارائه دهنده (Presenter) جایگزین می شود. ارائه دهندگان در همان سطح view قرار می گیرند ، و رویدادها را از طریق View و مدل مدیریت میکنند و اقدامات بین آنها را میانجی می کنند. بر خلاف MVVM ، مکانیزمی برای اتصال Views به ViewModels وجود ندارد ، بنابراین در عوض ما به هر View متکی هستیم که یک رابط کاربری را فراهم می کند تا ارائه دهنده بتواند با View تعامل داشته باشد.

الگوی MVVM به ما اجازه می دهد زیر مجموعه های View خاص یک مدل را ایجاد کنیم ، که می تواند حاوی اطلاعات حالت و منطق، با اجتناب از نیاز به قرار دادن کل مدل در معرض نمایش، باشد. بر خلاف ارائه دهنده MVP ، برای ارجاع به یک View نیازی به ViewModel نیست. View می تواند به خصوصیات ViewModel متصل شود ، که به نوبه خود داده های موجود در مدل ها را در معرض نمایش قرار می دهد. همانطور که اشاره کردیم ، انتزاع View به این معنی است که منطق کمتری در کد پشت آن وجود دارد.

با این حال یکی از نقاط ضعف این است که به سطح تفسیر بین ViewModel و View نیاز است و این می تواند هزینه های عملکردی داشته باشد. پیچیدگی این تفسیر می تواند متفاوت باشد: می تواند به سادگی کپی کردن داده ها یا به اندازه ی دستکاری آن در شکلی که دوست داریم View آن را ببیند، پیچیده باشد. MVC این مشکل را ندارد ، زیرا کل مدل به راحتی در دسترس است و می توان از چنین دستکاریهایی جلوگیری کرد.

مراجع:www.angularminds.com | www.oreilly.com