MVP против MVC против MVVM против VIPER. Что лучше для разработки под iOS?

Точно так же, как у каждого дома есть прочный фундамент, каждый программный проект, имеет программную архитектуру, на которой он построен, и каждый проект имеет свою собственную структуру приложений. Типы архитектурных паттернов могут различаться, но есть 4 наиболее часто используемых - те, которые весь ИТ-мир постоянно критикует, но продолжает использовать одновременно: MVC, MVP, MVVM и Viper (последний в основном как паттерн архитектуры iOS) . Сравнение этих шаблонов и выбор наиболее подходящего для каждого проекта, написанного на Swift, будет рассмотрен далее в этой статье.

Следуя хронологическому порядку вещей, как только появились первые шаблоны проектирования программного обеспечения, общие проблемы, связанные с этими шаблонами архитектуры разработки iOS, не заставили себя долго ждать.

Например, проблема взаимодействия сервер-клиент - как одно взаимодействует с другим? Или другой - проблема отделения бизнес-логики приложения от логики внутри приложения; как это должно работать с точки зрения архитектуры приложения? Благодаря им мир увидели различные шаблоны проектирования для разных слоев архитектуры; самые известные среди них:

- Шаблон проектирования Singleton.

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

- Декоратор дизайна шаблона.

В отличие от синглтона, этот шаблон (альтернативно называемый Wrapper вместе с шаблоном адаптера) позволяет добавлять определенное поведение к одному объекту (статически или динамически), и все это не влияет на поведение других объектов, которые один делит класс с.

- Шаблон проектирования моста.

Впервые представленный печально известной Бандой четырех - авторами книги «Паттерны проектирования», этот архитектурный паттерн «использует инкапсуляцию, агрегацию и может использовать наследование для разделения обязанностей между разными классами. программирование стало очень полезным, потому что изменения в программном коде могут быть легко внесены с минимальным предварительным знанием программы. [Источник: Wiki]

Несмотря на то, что эти шаблоны довольно разные, общие проблемы авторов кода возникали с каждым из них; например, с «массивностью» Синглтона. Синглтон слишком глобален, поскольку зависимости вашего кода глубоко скрыты внутри вашего приложения, а не отображаются в интерфейсах. Вот почему в процессе разработки программного обеспечения постоянно появляются новые закономерности.

Четыре наиболее часто используемых шаблона - это MVC, MVP, MVVM и VIPER (в основном для iOS).

Разработанные в том же порядке, что и перечисленные, все они имеют свои преимущества и недостатки, вызывая многочисленные споры о том, где применять каждый из них. Если уделить больше внимания лучшим практикам, которые они применяют, это может немного прояснить ситуацию.

Шаблон MVC

Дедушка всех программных шаблонов, впервые представленных в начале 1970-х норвежским компьютерным ученым Трюгве Ренскаугом, Module - View - Controller, широко известный как MVC, является одним из первых шаблонных подходов объектно-ориентированного программирования.

Часть View отвечает за отображение всего для пользователя системы (интерфейсы мобильного или веб-приложения и т. Д.). Модель обычно отвечает за базы данных, бизнес-объекты и остальные данные. В свою очередь, Контроллер регулирует работу Модели, данные, поступающие в базу данных, отображение из указанной базы данных в часть View и наоборот.

Какой бы универсальной ни была модель MVC, у двух крупнейших конкурентов - Apple и Google - есть свои собственные шаблоны, представляющие систему Модель - Представление - Контроллер. Проблема, с которой сталкивается система Apple, заключается в тесной связи между частями представления и контроллера, почти до такой степени, что они объединяют представление и контроллер и оставляют часть модели разделенной.

Следовательно, это приводит к плохому процессу тестирования - может быть исследована только Модель, V&C (из-за их плотного соединения) не может быть протестирован вообще.

Устойчивое соединение между сегментами «Контроллер» и «Просмотр» оказалось действительно «нездоровым», когда дело доходит до программного обеспечения, поэтому вскоре мир увидел новую модель.

Шаблон MVP.

Многие из нас слышали об этом сокращении в контексте минимально жизнеспособного продукта, но с точки зрения разработки программного обеспечения это означает нечто иное. Паттерн Model View Presenter имеет несколько ключевых моментов, образующих огромную пропасть между ним и MVC:

Модель MVP

• Вид более слабо связан с моделью. Презентатор отвечает за привязку модели к представлению.

• Модульное тестирование проще, потому что взаимодействие с представлением осуществляется через интерфейс.

• Обычно View to Presenter = сопоставление один-к-одному. Сложные представления могут иметь несколько докладчиков.

Шаблон MVC

• Контроллеры основаны на поведении и могут использоваться во всех представлениях.

• Может отвечать за определение представления для отображения
  [Источник: Infragistics]

В этом расположении функции модели остаются прежними; Presenter отвечает за бизнес-логику соответственно. Часть V представляет особый интерес, поскольку она разделена на две части: View и View Controller, которые отвечают за взаимодействие. Когда возникает вопрос о MVVM и MVC, система этого типа решает проблему «сильной зависимости» от режимов View и Controller, которые использовались в шаблоне MVC.

В этом случае также устраняется препятствие для тестирования, так как модели, представление с взаимодействием с пользователем и презентатор - все они могут быть протестированы.
Пока еще существующее неудобство связано с Presenter, но оно слишком велико, но учитывает всю существующую бизнес-логику. Поэтому в игру вступил следующий акт, названный…

Шаблон MVVM

Архитектурный шаблон программного обеспечения « Модель-представление-представление- модель» был создан в 2005 году Джоном Госсманом, одним из архитекторов Microsoft. Три основных компонента модели MVVM соответственно:
Модель - это «реализация модели предметной области приложения, которая включает модель данных вместе с бизнес-логикой и логикой проверки. Примеры объектов модели включают репозитории, бизнес-объекты, объекты передачи данных (DTO), обычные старые объекты CLR (POCO), а также сгенерированные объекты сущностей и прокси-объекты ». [Источник: Microsoft]

Просмотр - это снова все, что пользователь может видеть - макет, структура и внешний вид всего на экране. По сути, внутри приложения это будет страница приложения. View получает и отправляет обновления только ViewModel, исключая всю связь между этой частью и самой моделью.

ViewModel должен быть «связующей цепочкой» между компонентами системы View и Model, и его основная функция - обрабатывать логику View. Обычно модель представления взаимодействует с моделью, вызывая методы в классах модели. Затем модель представления предоставляет данные из модели в форме, которую представление может легко использовать, как заявляет Microsoft.

Основное различие между MVC и iOS MVVM заключается в том, что шаблон распределения MVVM лучше, чем в ранее перечисленном MVC, но по сравнению с MVP он также сильно перегружен. Здесь тестирование имеет особую важность, так как при простом написании кода вы не можете гарантировать, что весь проект будет работать должным образом - тесты, на яркой ноте, помогают убедиться, что это будет.

Недавно была выпущена следующая эволюция архитектурных паттернов, и теперь это самый свежий архитектурный подход к программному обеспечению.

Архитектура iOS VIPER

В поисках лучшего архитектурного решения разработчики iOS во всем мире столкнулись с так называемым подходом «чистой архитектуры», предложенным дядей Бобом на Clean Coders - известной платформе, на которой проводятся тренинги для профессионалов программного обеспечения во всем мире.

Чистая архитектура разделяет логическую структуру приложения на несколько уровней ответственности. В свою очередь, это «разделение» решает проблемы тесной зависимости и увеличивает доступность тестирования на всех уровнях.

VIPER для разработки под ios

VIPER - это реализация чистой архитектуры для приложений, созданных под iOS. Как общее правило для имен всех шаблонов, это также бэкроним для View, Interactor, Presenter, Entity и Routing. Каждая из частей VIPER отвечает за определенный элемент, в частности:

1. View отвечает за зеркальное отображение действий пользователя с интерфейсом.

2. Обязанности Presenter в шаблоне VIPER весьма ограничены - он получает обновления от Entity, но не отправляет ему никаких данных;

3. Interactor - это часть системы, которая фактически соответствует Entities. Эта схема работает в следующем направлении: Presenter информирует Interactor об изменениях в модели View, затем Interactor связывается с частью Entity, и с данными, полученными от Entity Interactor, возвращается в Presenter, который командует View, чтобы отразить их для пользователя. Все модели данных, все сущности и все веб-сайты подключены к интерактивной части.

4. Сущность состоит из объектов, которые контролируются Interactor (заголовки, контент и т. Д.). Она никогда не взаимодействует с Presenter напрямую, только через I-часть.

5. Маршрутизация (или Wireframe, как ее иногда называют) отвечает за навигацию между всеми экранами и, по сути, за маршрутизацию. Wireframe управляет объектами UIWindow, UINavigationController и так далее.

В частности, в архитектурной системе iOS все построено на фреймворке UIkit, который включает в себя все компоненты Apple MVC, но без тесной связи, которая раньше сводила кодеров с ума.

Модуль VIPER также полезен, когда дело доходит до модульных тестов, поскольку отличный дистрибутив шаблона позволяет вам тестировать весь доступный функционал. Во многих отношениях это было основной трудностью, с которой столкнулись разработчики при использовании предыдущих программных шаблонов MVC, MVP и MVVM.

Венчать все.

Все эти 4 шаблона проектирования программного обеспечения часто называют одними из лучших шаблонов архитектуры для разработки iOS, хотя все они далеко не идеальны и определенно не используются повсеместно для каждого проекта, который вы разрабатываете. С мрачной стороны, вот краткий список проблем, которые есть у каждого шаблона:

• MVC, MVP, MVVM - все они имеют проблему «плотного соединения», из-за которой внедрение обновлений в разработку и последующее их тестирование является довольно сложной задачей.

• VIPER против MVVM, MVC или MVP считается выигрышным случаем; хотя, несмотря на его высокую гибкость и отличную тестируемость, также есть много нюансов, которые трудно уловить.

Есть 100% твердый раствор? Не совсем, но для каждого из ваших проектов один из этих 4 шаблонов приложений iOS может быть именно тем, что вам нужно. А если нет, то смесь двух будет. А может, три. Говорят, что удача любит смелых, так почему бы вам смело не поиграть с шаблонами разработки программного обеспечения?

Авторы Макс Машков и Элина Бессарабова.