Повышаем свою стоимость: MVP, MVVM

Пополняем коллекцию аббревиатур. Начали с MVC, закончим за упо... MVP и MVVM. Тут можно обойтись малой кровью, потому что M и V в этих ребятах абсолютли те же самые, а именно "Model" и "View" (рассматривается здесь).

Как вы помните, разработчики придумали паттерны для решения одних и тех же задач, разве что с небольшими изменениями. Разумеется, на одном паттерне MVC дело не остановилось, потому вылезли другие представители "MV-whatever". Самые известные - MVP и MVVM, но есть и другие, не такие популярные, но все же занимающие определенное место в этой модельно-видовой системе.

Паттерн MVP

По картинке может показаться, что MVP не особо отличается от MVC. В этом проблема схемок. Хотя, можно упороться и разрисовать все очень подробно в диаграммах. Кому как нравится.

В чем главная задача паттерна MVC? Отделить бизнес-логику от представления и организовать отображение этой самой логики в представлении с помощью еще одного слоя, в данном случае, Контроллера. Если вдаваться в подробности, то каждая из этих частей представляет собой сложную структуру. Та же Модель - не только хранилище данных (так называемая Domain Model), но и логика работы с ними. Хотя есть варианты, когда логику работы с данными уносят в Контроллеры, делая их "толстыми" (там есть еще два слова, но не будем обижать наши Контроллеры), а Модель "бледной". Короче, все срутся и кидаются друг в друга какашками, решая, где именно размещать бизнес-логику и как организовать взаимодействие. Но есть же еще Представление.

Обычно в MVC Представление вызывает методы Контроллера и ждет, когда можно будет обновиться. Его обновит или Контроллер, если ему известно, какое именно Представление нужно обновить, либо Представление подпишется на события, которые будет бросать Модель после обновления (механизм "Подписчик/Издатель", или "PubSub", обычно реализуется паттерном "Observer"). Но что, если Представление имеет довольно сложную структуру и у него есть своя "ничесекакая" логика. Посмотрите на современные UI на сайтах, мобилках, десктопах - это ж уму непостижимо, сколько там логики крутится. И хочется как-то эту логику отделить от, собственно, пользовательского интерфейса. И на помощь приходят другие паттерны.

В MVP буква "P" - это Presenter ("Представитель" - всегда почему-то режет глаз и слух это слово при переводе на русский, буду писать "Презентер"), и он заменяет Controller в классическом MVC. Общение между Представлением и Презентером осуществляется через интерфейс, точнее, Презентер знает об интерфейсе, который реализует Представление. Таким образом, Презентер может обновлять Представление, не парясь ваааааще, как именно выглядит Представление. Ну и работает с Моделью, как и Контроллер. Короче, Представление делают максимально простым, а всю логику уносят в Презентер. Это и для понимания хорошо, и для тестирования отлично.

MVP хорошо прижился в мобильной разработке (Andorid, iOS), но можно и в Вебе его прикрутить. Например, есть такая реализация, почему бы и нет. Это ж паттерн, подбирай для него нужные инструменты и вперед, с танцами и бубном, как программисты любят.

Паттерн MVVM

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

Шутки шутками, но, как я говорил, просто так ничего не придумывается, это всегда решение задач, возникших перед многими разработчиками. И еще одним решением для адекватного отделения зерен от плевел является паттерн "Model - View - ViewModel".

Щито там в конце написано? ПредставлениеМодель? Модель Представления? Представление Модели? Представители и Модели? Блэкджек и ...

Фишка данного паттерна - в связывании (binding). Неспроста третья сущность называется ViewModel - она является посредником между Моделью и Представлением, включает в себя, с одной стороны, получение команд от Представления, с другой, она обновляет Модель и сразу же приводит Представление в согласованное состояние. То есть, что-то поменялось в Модели, и ViewModel обновила Представление, или Представление послало команду в ViewModel и тоже обновилось. Как будто Представление и Модель общаются напрямую, но нет, в них есть посредник (есть такой поведенческий паттерн, "Mediator").

Кстати, MVVM зародилось в недрах .Net царства, точнее, WPF, потом уже перекатило в другие области (Android и iOS в том числе, не одним MVP едины). Поэтому, вам часто будет попадаться статьи об MVVM в контексте творения мелкомягких. Например, тут.

Итого

Может показаться, что все эти MVW ("Model - View - Whatever") вообще ничем не отличаются друг от друга. Но это именно что кажется. Каждый из них решает свой круг задач, вам нужно просто знать об этих вещах и немного разбираться. Потому что полноценное понимание придет только на практике, когда вы конкретно возьмете MVC или MVP и на любимом языке программирования запилите приложение по этому паттерну.

Более того, большое количество веб-фреймворков уже реализуют паттерн MVC из коробки, вам нужно только следовать документации, реализуя нужную логику. Гуглите "{ваш ЯП} mvc framework" и вперед, через тернии к слезам и боли. Ну шо поделать, работа такая, всю жизнь учиться и страдать.