Разница между шаблоном архитектуры MVC, MVP и MVVM в Android
Разработчики всегда предпочитают разработку приложения для Android с применением шаблона архитектуры программного обеспечения. Шаблон архитектуры придает модульность файлам проекта и гарантирует, что все коды будут охвачены модульным тестированием. Это облегчает разработчикам задачу по сопровождению программного обеспечения и расширению функций приложения в будущем. MVC (Model - View - Controller), MVP (Model - View - Presenter) и MVVM (Model - View - ViewModel) - самый популярный и признанный в отрасли шаблон архитектуры Android среди разработчиков.
Шаблон "Модель — Представление — Контроллер" (MVC)
Шаблон MVC предлагает разделить код на 3 компонента. При создании класса / файла приложения разработчик должен разделить его на один из следующих трех уровней:
- Модель: этот компонент хранит данные приложения. Он ничего не знает об интерфейсе. Модель отвечает за обработку логики предметной области (бизнес-правила реального мира) и взаимодействие с базой данных и сетевыми уровнями.
- Представление: это слой пользовательского интерфейса (пользовательского интерфейса), который содержит компоненты, видимые на экране. Кроме того, он обеспечивает визуализацию данных, хранящихся в модели, и предлагает взаимодействие с пользователем.
- Контроллер: этот компонент устанавливает связь между представлением и моделью. Он содержит основную логику приложения, получает информацию об ответе пользователя и обновляет Модель в соответствии с потребностями.
Шаблон "Модель - представление - докладчик" (MVP)
Шаблон MVP преодолевает проблемы MVC и предоставляет простой способ структурировать коды проекта. Причина, по которой MVP получил широкое распространение, заключается в том, что он обеспечивает модульность, тестируемость, а также более чистую и удобную в обслуживании кодовую базу. Он состоит из следующих трех компонентов:
- Модель: слой для хранения данных. Он отвечает за обработку логики предметной области (бизнес-правила реального мира) и связь с базой данных и сетевыми уровнями.
- Вид: слой UI (пользовательского интерфейса). Он обеспечивает визуализацию данных и отслеживает действия пользователя, чтобы уведомить ведущего.
- Presenter: извлекает данные из модели и применяет логику пользовательского интерфейса, чтобы решить, что отображать. Он управляет состоянием представления и выполняет действия в соответствии с уведомлением пользователя о вводе из представления.
Модель - представление - шаблон ViewModel (MVVM)
Шаблон MVVM имеет некоторое сходство с шаблоном проектирования MVP (Модель - Представление - Презентатор), поскольку роль Презентатора играет ViewModel. Однако недостатки шаблона MVP были устранены с помощью MVVM. Он предлагает отделить логику представления данных (представления или пользовательский интерфейс) от основной части бизнес-логики приложения. К отдельным слоям кода MVVM относятся:
- Модель: этот уровень отвечает за абстракцию источников данных. Модель и ViewModel работают вместе, чтобы получить и сохранить данные.
- Представление: цель этого уровня - информировать ViewModel о действиях пользователя. Этот уровень соответствует ViewModel и не содержит никакой логики приложения.
- ViewModel: предоставляет те потоки данных, которые имеют отношение к View. Более того, он служит связующим звеном между моделью и представлением.
Разница между шаблоном проектирования MVC, MVP и MVVM
MVC (КОНТРОЛЛЕР ВИДА МОДЕЛИ) | MVP (ПРЕДСТАВИТЕЛЬ ВИДА МОДЕЛИ) | MVVM (МОДЕЛЬ ВИД ВИД МОДЕЛЬ) |
|---|---|---|
| Одна из старейших программных архитектур | Разработан как вторая итерация архитектуры программного обеспечения, усовершенствованная от MVC. | Признанный в отрасли образец архитектуры для приложений. |
| Пользовательский интерфейс ( представление ) и механизм доступа к данным ( модель ) тесно связаны. | Это решает проблему наличия зависимого представления за счет использования Presenter в качестве канала связи между моделью и представлением . | Этот шаблон архитектуры в большей степени ориентирован на события, поскольку он использует привязку данных и, таким образом, упрощает отделение основной бизнес-логики от представления . |
| Контроллер и представление существуют с отношением «один ко многим». Один контроллер может выбрать другой вид в зависимости от требуемой операции. | Между Presenter и View существует взаимно-однозначная связь, поскольку один класс Presenter управляет одним View одновременно. | Множественное представление можно сопоставить с одной моделью представления, и, таким образом, между представлением и моделью представления существует отношение «один ко многим». |
| Представление ничего не знает о Контроллере . | В представлении есть ссылки на докладчика . | View имеет ссылки на ViewModel |
| Сложно вносить изменения и модифицировать функции приложения, поскольку слои кода тесно связаны. | Уровни кода слабо связаны, поэтому легко выполнять модификации / изменения в коде приложения. | Легко вносить изменения в приложение. Однако, если логика привязки данных слишком сложна, отладить приложение будет немного сложнее. |
| Пользовательский ввод обрабатывается контроллером . | Представление - это точка входа в приложение. | Представление принимает ввод от пользователя и действует как точка входа в приложение. |
| Идеально подходит только для небольших проектов. | Идеально подходит для простых и сложных приложений. | Не идеален для небольших проектов. |
| Ограниченная поддержка модульного тестирования . | Простое выполнение модульного тестирования, но тесная связь View и Presenter может немного затруднить его. | Тестируемость модулей самая высокая в этой архитектуре. |
| Эта архитектура сильно зависит от API Android. | Он слабо зависит от API Android. | Имеет слабую или нулевую зависимость от Android API. |
| Он не следует принципу модульности и единой ответственности. | Следует принципу модульности и единой ответственности. | Следует принципу модульности и единой ответственности. |