Разлика между MVVM и MVP

Целта на разработката на софтуер е да създаде решения, които да адресират нуждите и проблемите за потребителите и бизнеса. За да се постигне това, различни технологии и архитектурни модели харесват Модел-View-ViewModel (MVVM) и Представяне на модел-изглед (MVP) са използвани.

Както при всичко, което се произвежда, първата стъпка е етапа на планиране и проектиране. Процесът на проектиране на софтуер може да бъде спецификация на базата на предпочитания набор от инструменти за технологии и може да обхваща всички дейности от концепцията - до - планирането - до - прилагането - до - актуализации и модификации.

Той обхваща архитектурния дизайн на ниско и високо ниво, базиран на избрани модели на архитектура, и извежда решения за многократна употреба, използвайки дизайнерски модели.

Структура на софтуерното приложение

Софтуерната архитектура дефинира структурата на приложението, която отговаря на техническите, оперативните и потребителските изисквания и се отнася до това как кодът е организиран и управляван.

Вземането на решение за архитектурата на софтуерното приложение е от решаващо значение, тъй като не е лесна, променяща се част от приложение, което вече е разработено; следователно архитектурният модел трябва да бъде определен преди да започне програмирането.

Архитектурните модели донякъде се различават от моделите на проектиране, тъй като техният обхват е много по-широк, като адресира повече технически проблеми като хардуерната производителност и ограниченията и високата достъпност. Примери за различни модели на архитектура са MVC, MVVM и MVP.

От друга страна, моделите на дизайн са формализирани най-добри практики, които улесняват обектно-ориентираното развитие за многократна употреба и са по-лесни за поддържане и промяна от архитектурата на приложението. 

Модели на архитектурата

Контролер за изглед на модел (MVC) беше един от първите архитектурни модели, разработени за уеб приложения, набира популярност от средата до края на деветдесетте години, особено при общността на Java.

По-новите рамки като Django за Python и Rails (Ruby on Rails) имат силен акцент върху бързото внедряване, поради което MVC заема пазарния дял като голямата атракция в архитектурните модели.

Традиционно разработката на потребителски интерфейс съдържаше много код за обработка на сложна логика, така че моделите на архитектурата са проектирани да намалят кода на ниво потребителски интерфейс (UI), което го прави по-чист и управляем.

Така че, с MVC модела, уеб приложение е съставено от

• Модел (данни)
• изглед (интерфейс за преглед и манипулиране на данни)
• контрольор (операции и действия, извършени върху данните)

Най- Модел обработва данни и бизнес логика и има не зависимости между Модел и на контрольор или изглед.

Най- изглед представя данните на потребителя в поддържания формат и необходимото оформление и кога контрольор получава потребителски заявки (за получаване на данни), той извиква съответните ресурси, необходими за завършване на заявката.

Нека приложим този модел за изграждане на онлайн магазин за книги.

Потребителите могат да търсят, разглеждат, регистрират и купуват книги, както и да управляват техните профили и списъци с книги. Когато потребителят кликне върху категорията SCI-FI, всички свързани книги трябва да се показват, както са налични.

Най- Контрольори борави с действията, които управляват книгите (списък, добавяне, преглед и т.н.). Може да има множество Контрольори с една основна контрольор „насочване на трафика“.

За този пример контрольор е кръстен контролер_books.php и Модел (напр. model_books.php) обработва данните и логиката, свързани с книгите.

И накрая, различно Прегледи ще се изискват, като например при добавяне на книги в онлайн количката или при разглеждане на детайла на книгата с изображения и рецензии.

Най- controller_books.php получава действието (потребителска заявка) от главния контрольор (например. index.php). Най- controller_books.php анализира заявката и се обажда на model_books.php (данните) за връщане на списъка с SCI-FI книги.

Отговорността на Модел е да предоставим тази информация, използвайки всяка логика, която е била приложена (използвайки филтри за търсене). Най- контрольор след това взема информацията и я предава на съответната изглед (изглед за търсене, изглед за печат, изглед с подробности и т.н.) и информацията се представя (чрез изглед) на потребителя, инициирал заявката.

Това е основата на MVC модела, който е развил нередовни вариации на архитектурни модели, като Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchical-Model-View-Controller (HMVC), и адаптер за изглед на модел (MVA) и т.н..

MVP модел

Представяне на модел-изглед (MVP)

Най- MVP модел съществува от известно време и е вариант на MVC. Той е създаден специално за тестова автоматизация, където целта е била да се увеличи количеството код, който може да бъде тестван чрез автоматизация, а моделът адресира някои проблеми с презентационния слой, изолирайки бизнес логиката от потребителския интерфейс.

Екранът е изглед, данните, които показва, са модела, а презентаторът закача двете заедно.

MVP включва следните компоненти с отделни отговорности:

• Модел (определя данните, които ще се показват)
• изглед (показва данните от Модела и маршрутизира потребителски заявки към презентатора).
• дарител (взаимодейства между изгледа и модела и ги закача заедно)

Най- изглед (уеб страница) показва и управлява контролите на страницата, като препраща събития (потребителски заявки) към дарител които бяха инициирани през изглед.

Най- дарител отговаря на тези събития чрез четене и актуализиране на Модел за промяна на изглед и следователно Водещи отговорността е да се обвърже Модел и изглед.

След като погледнах MVC и MVP модели, общото е и двете да имат отделни отговорности за всеки компонент и те насърчават разделянето между изглед (Потребителски интерфейс) и Модел (данни). Значителните разлики между тези модели са по-очевидни в начина, по който моделите се осъществяват.

MVP може да е сложен модел за прилагане на модерни решения, но със сигурност има големи ползи, ако се прилага като добре проектирано решение, въпреки че не е задължително да е подходящият избор за прости решения.

MVVM модел

Модел-View-ViewModel (MVVM)

Най- MVVM модел е разработен специално за Windows Presentation Foundation (WPF) и Microsoft Silverlight платформи и може да се използва за всички XAML [Ь] платформи.

WPF е система на Microsoft, която предоставя потребителски интерфейси в програми, базирани на Windows и за първи път е пусната в .NET Framework 3.0.

MVVM беше рафиниран от MVC и в този модел изглед е активен с поведения, събития и обвързване на данни и изглед синхронизира с ViewModel (което дава възможност за разделяне на презентацията и излага методи и команди за управление и манипулиране на Модел.

MVVM съдържа три основни компонента:

• Модел (представлява данните с валидиране и бизнес логика)
• изглед (Изгледът е отговорен за дефинирането на структурата, оформлението и външния вид на това, което потребителят вижда на екрана. В идеалния случай изгледът е дефиниран чисто с XAML, с ограничен код отзад, който не съдържа бизнес логика. обвързване между изглед и ViewModel за показване на възможност за синхронизиране на модела и ViewModel с изгледа)
• ViewModel (отделя изгледа от модела и излага методи и команди за манипулиране на данните (модел).

Най- изглед получава данни от ViewModel (чрез обвързване на данни и методи), и по време на изпълнение, изглед ще се промени, когато реагира на събития в ViewModel.

Най- ViewModel посредничи между изглед и Модел и се справя с изглед логика. Той взаимодейства с Модел - вземане на данните от Модел и го представя на изглед за показване.

Всички тези компоненти са отделени един от друг, което позволява по-голяма гъвкавост за работа върху тях независимо, изолиране на тестване на единици и размяна на тях, без да се засяга друг компонент.

Тази структура позволява на Модел и други компоненти да се развиват независимо, което позволява на разработчиците да работят по различни аспекти на решението едновременно. Например, където дизайнерите работят върху изглед, те просто генерират извадки от данни, без да се нуждаят от достъп до другите компоненти. Това улеснява лесното препроектиране на потребителския интерфейс като изглед се реализира в XAML.

Както споменахме преди с MVP, прости решения не се нуждаят от архитектурни и дизайнерски модели, като "Hello World!" е твърде основно, за да следвате всеки модел; Въпреки това, с въвеждането на повече функции, функции и компоненти, сложността на приложението нараства и с това увеличава количеството код, което трябва да се управлява.

В обобщение

От началото на разработката на потребителски интерфейс, моделите на дизайн стават все по-популярни, за да улеснят процеса на разработка, приложенията по-мащабируеми и това улеснява по-лесното тестване.

Илюстрирана разлика между MVP и MVVM модели:

• И в двете MVP и MVVM, на изглед е входната точка на приложението
• в MVP, има едно към едно картографиране между изглед и дарител, къде в MVVM, връзката е една към много между изглед и ViewModel.
• MVP се използва предимно за Windows Forms и Windows Phone приложения и MVVM е проектиран за Silverlight, WPF, Knockout / AngularJS и др.