«1. Обзор
В этом руководстве мы узнаем о шаблонах контроллера представления модели и презентатора представления модели. Мы также обсудим различия между ними.
2. Шаблон проектирования и архитектурный шаблон
2.1. Архитектурный шаблон
Архитектурные шаблоны — это общие, многократно используемые решения часто встречающихся проблем в архитектуре программного обеспечения. Они сильно влияют на кодовую базу.
Например, они влияют на программное обеспечение как горизонтально, так и вертикально. Под горизонтальностью мы подразумеваем, как структурировать код внутри слоя. И наоборот, по вертикали означает, как обрабатывается запрос от внешних слоев к внутренним уровням и обратно.
Одними из наиболее распространенных архитектурных шаблонов являются MVC, MVP и MVVM.
2.2. Шаблон проектирования
Шаблоны проектирования обычно связаны с общими элементами на уровне кода. Они предоставляют различные схемы для уточнения и построения более мелких подсистем.
Кроме того, шаблоны проектирования — это тактика среднего масштаба, конкретизирующая некоторые структуры и поведение сущностей и их взаимосвязей. Некоторыми часто используемыми шаблонами проектирования являются шаблоны singleton, factory и builder.
Шаблоны проектирования отличаются от архитектурных шаблонов своей областью применения. Они более локализованы и меньше влияют на кодовую базу. Вместо этого они влияют только на определенный раздел кодовой базы. В следующем разделе мы поговорим о том, почему мы используем эти шаблоны.
3. Зачем нужны шаблоны MVC и MVP
Основной идеей использования этих шаблонов является разделение задач между бизнес-уровнем и уровнем пользовательского интерфейса. Эти шаблоны предоставляют нам такие функции, как простота тестирования. Они также скрывают доступ к данным.
Можно сказать, что они лучше адаптируются к изменениям, изолируя основные компоненты. Тем не менее, самые большие недостатки добавляют сложность и кривую обучения.
4. Шаблон MVC
В шаблоне MVC функции разделены на три компонента, основанные на трех отдельных задачах. Во-первых, представление отвечает за отрисовку элементов пользовательского интерфейса. Во-вторых, контроллер реагирует на действия пользовательского интерфейса. И модель обрабатывает бизнес-поведение и управление состоянием.
В большинстве реализаций все три компонента могут напрямую взаимодействовать друг с другом. Однако в некоторых реализациях контроллер отвечает за определение того, какое представление отображать.
На диаграмме ниже показан поток управления MVC:
Модель представляет весь уровень бизнес-логики. Представление представляет данные, полученные из модели. Кроме того, он обрабатывает логику представления. Наконец, контроллер обрабатывает логику потока управления и обновляет модель.
MVC не определяет внутреннюю структуру представления и модели. Обычно уровень представления реализуется в одном классе.
Однако в этом случае может возникнуть несколько проблем:
-
Представление и модель тесно связаны. В результате требования к функциям представления могут легко просачиваться в модель и загрязнять уровень бизнес-логики. Представление является монолитным и обычно тесно связано с инфраструктурой пользовательского интерфейса. Таким образом, модульное тестирование представления становится затруднительным
5. Шаблон MVP
Шаблон MVP — это шаблон представления пользовательского интерфейса, основанный на концепциях шаблона MVC. Однако в нем не указано, как структурировать всю систему. Это только диктует, как структурировать представление.
Этот шаблон разделяет обязанности по четырем компонентам в целом. Во-первых, представление отвечает за рендеринг элементов пользовательского интерфейса. Во-вторых, интерфейс представления используется для слабой связи ведущего с его представлением.
Наконец, ведущий взаимодействует с представлением и моделью, а модель отвечает за бизнес-поведение и управление состоянием.
В некоторых реализациях презентатор взаимодействует со слоем сервиса (контроллера) для извлечения/сохранения модели. Интерфейс представления и сервисный уровень обычно используются для упрощения написания модульных тестов для презентатора и модели.
На приведенной ниже диаграмме показан поток управления MVP:
«Модель такая же, как в MVC и содержит бизнес-логику. Представление — это пассивный интерфейс, отображающий данные. Он отправляет действия пользователя докладчику.
Ведущий сидит между моделью и представлением. Он запускает бизнес-логику и позволяет обновлять представление. Он получает данные от модели и показывает их в представлении. Это значительно упрощает тестирование презентатора.
Тем не менее, есть некоторые проблемы с MVP:
-
Контроллер часто опускается. Из-за отсутствия контроллера поток управления также должен обрабатываться докладчиком. Это возлагает на докладчика ответственность за две задачи: обновление модели и представление модели. Мы не можем использовать привязку данных. Если связывание возможно с инфраструктурой пользовательского интерфейса, мы должны использовать его для упрощения презентатора
6. Реализация MVC и MVP
Мы поймем шаблоны на простом примере. У нас есть продукт, который нужно показать и обновить. Эти действия обрабатываются по-разному в MVC и MVP.
6.1. Класс представления
У нас есть простой класс представления, который выводит сведения о продукте. Класс представления для MVP и MVC одинаков:
public class ProductView {
public void printProductDetails(String name, String description, Double price) {
log.info("Product details:");
log.info("product Name: " + name);
log.info("product Description: " + description);
log.info("product price: " + price);
}
}
6.2. Модель MVP и классы презентаторов
Давайте теперь определим класс Product для MVP, который отвечает только за бизнес-логику:
public class Product {
private String name;
private String description;
private Double price;
//getters & setters
}Класс презентаторов в MVP извлекает данные из модели и передает их в представление: ~ ~~
public class ProductPresenter {
private final Product product;
private final ProductView view;
//getters,setters & constructor
public void showProduct() {
productView.printProductDetails(product.getName(), product.getDescription(), product.getPrice());
}
}6.3. Класс модели MVC
Для MVC разница в том, что представление будет получать данные из класса модели, а не из класса презентатора в MVP.
Мы можем определить класс модели для MVC:
public class Product {
private String name;
private String description;
private Double price;
private ProductView view;
//getters,setters
public void showProduct() {
view.printProductDetails(name, description, price);
}
}
Обратите внимание на метод showProduct(). Этот метод обрабатывает передачу данных из модели в представление. В MVP это делается в классе презентатора, а в MVC — в классе модели.
7. Сравнение между MVC и MVP
Между MVC и MVP не так уж много различий. Оба шаблона сосредоточены на разделении ответственности между несколькими компонентами, следовательно, способствуют слабой связи пользовательского интерфейса (представления) с бизнес-уровнем (моделью).
Основные различия заключаются в том, как реализуются шаблоны, и в некоторых сложных сценариях. Давайте рассмотрим некоторые из ключевых отличий:
-
Связывание: Представление и модель тесно связаны в MVC, но слабо связаны в MVP Связь: В MVP связь между View-Presenter и Presenter-Model происходит через интерфейс. Однако уровень контроллера и представления попадает в одно и то же действие/фрагмент пользовательского ввода MVC: в MVC вводимые пользователем данные обрабатываются контроллером, который инструктирует модель для дальнейших операций. Но в MVP пользовательский ввод обрабатывается представлением, которое инструктирует ведущего вызывать соответствующие функции. Тип отношения: между контроллером и представлением существует отношение «многие к одному». Один контроллер может выбирать разные представления в зависимости от требуемых операций в MVC. С другой стороны, презентатор и представление имеют отношение один к одному в MVP, где один класс презентатора одновременно управляет одним представлением. Основной компонент: в MVC за это отвечает контроллер. Он создает соответствующий вид и взаимодействует с моделью в соответствии с запросом пользователя. Наоборот, в MVP главное — представление. Методы вызова представления в презентаторе, который дополнительно направляет модульное тестирование модели: из-за тесной связи MVC имеет ограниченную поддержку модульного тестирования. С другой стороны, модульное тестирование хорошо поддерживается в MVP
8. Почему MVP имеет преимущество перед MVC
MVP имеет небольшое преимущество перед MVC, поскольку оно может разбить наше приложение на модули. Таким образом, мы можем избежать необходимости постоянно создавать представления. Другими словами, MVP может помочь сделать наши представления многоразовыми.
9. Заключение
В этом руководстве мы рассмотрели архитектурные шаблоны MVC и MVP и сравнили их.
Код примера доступен на GitHub.