В чем отличия между MVC и MVP шаблонами?

1. Обзор

В этом руководстве мы узнаем о шаблонах Model View Controller и Model View Presenter. Мы также обсудим различия между ними.

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
}

Класс Presenter в 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 .