Шаблон проектирования MVP

Перед прочтением данной статьи настоятельно рекомендую ознакомиться с предыдущей статьей, в которой мы рассмотрели базовый шаблон проектирования MVC.

Итак, в предыдущей статье мы рассмотрели шаблон проектирования MVC модель, представление и контроллер. Этот шаблон не является универсальным, так как связи между слоями таковы — контроллер передает данные модели, модель обновляет данные и передает их представлению. В предыдущей статье мы отметили, что MVC не совсем подходит для разработки андроид приложений, так как в современных мобильных устройствах пользователь взаимодействует с экраном, на котором и видит данные, т.е. экран мобильного устройства это и контроллер и представление.

Именно поэтому был создан шаблон проектирования MVP. Прочитаем описание в википедии.

MVP — шаблон проектирования пользовательского интерфейса, который был разработан для облегчения автоматического модульного тестирования и улучшения разделения ответственности в презентационной логике (отделения логики от отображения):

  • Модель (англ. Model) — хранит в себе всю бизнес-логику, при необходимости получает данные из хранилища.
  • Вид (англ. View) — реализует отображение данных (из Модели), обращается к Presenter за обновлениями.
  • Представитель (англ. Presenter) — реализует взаимодействие между моделью и представлением.

Картинки по запросу model view presenter

Теперь пользователь взаимодействует с видом (представлением), данные передаются презентеру, дальше они передаются в модель, в нем происходит обработка и возврат в презентер и из него уже передаются данные в представление.

Суть шаблона MVP именно в том, что представление и модель данных не имеют прямой связи и «ничего не знают друг о друге». А единым связующим звеном является презентер.

Давайте рассмотрим простейший код для разработки андроид.

Выделяем интерфейс, в котором будут методы отображения прогресса, скрытия и отображение данных (на вход будет принимать некий объект, содержащий необходимые для отображения данные).

Дальше необходим интерфейс для модели. В нашем случае это будет получение данных из сети.

Реализация модели может выглядеть таким образом.

В конструкторе передается инстанс презентера и при получении данных передается ему.

Теперь написать интефейс для презентера не составит труда, так как он должен иметь в себе методы и модели и вью.

Теперь напишем реализацию презентера.

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

Теперь напишем реализацию вью. В андроид это будет Активити.

Итак, на экране есть поле ввода, текст для отображения (может быть что угодно) и кнопка, при нажатии на которую идет поиск. В методе onCreate инициализируем презентер, элементы отображения и устанваливаем обработчик нажатия на кнопку, при котором лишь вызываем метод у презентера. Переопределяем методы представления в каждом из которых прописываем код для отображения.

Как видим в каждом классе количество кода минимально и предельно понятно для чтения. Большего всего кода будет лишь в классе Модели, так как там будет происходить запрос-ответ от сервера. Как видим, если нам необходимо будет также отобразить некую ошибку (например сервер недоступен), то для этого необходимо лишь добавить метод в интерфейс вью, он автоматом перенесется в презентер, где опять вызовем у вью и еще надо будет добавить в класс модели вызов метода вью если что-то пойдет не так. А в активити это например будет всплывашка (тоаст).

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

Запись опубликована в рубрике Программирование Android, Программирование Java. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *