Когда мы разрабатываем сложное приложение, мы обычно сталкиваемся с проблемами, которые, возможно, решались ранее и уже имеют довольно хорошие решения. Такие решения часто называют шаблонами. Обычно мы говорим о шаблонах проектирования и архитектурных схемах . Они упрощают разработку, и мы должны использовать их, когда это уместно.
Это руководство должно помочь вам понять важность хорошо спроектированного проекта и почему стандартной архитектуры Android не всегда достаточно. Мы обсудим несколько потенциальных проблем, с которыми вы можете столкнуться при разработке приложений для Android, и я покажу вам, как решить эти проблемы, улучшив тестируемость и надежность приложения с помощью шаблона Model View Presenter (MVP).
В этом уроке мы рассмотрим:
- ценность применения известных архитектурных шаблонов в программных проектах
- почему может быть хорошей идеей изменить стандартную архитектуру Android
- ключевые понятия, лежащие в основе шаблона Model View Presenter (MVP)
- различия между MVC и MVP
- как MVP соответствует Android SDK
В первой части этого урока мы сосредоточимся на теории паттерна MVP. Вторая часть этого урока более практична.
1. Архитектура Android
Дизайн проекта должен быть предметом заботы с самого начала. Одной из первых вещей, которые мы должны рассмотреть, является архитектура, которую мы планируем принять, поскольку она будет определять, как различные элементы нашего приложения связаны друг с другом. Он также установит некоторые основные правила, которыми мы будем руководствоваться при разработке.
В целом, фреймворк или SDK ожидают, что что-то будет сделано определенным образом, но это не всегда подходит для проекта. Иногда не существует заранее определенного или правильного способа выполнения действий, оставляя проектные решения на усмотрение разработчика. Android SDK ожидает, что все будет сделано определенным образом, но этого не всегда достаточно или лучший выбор.
Хотя Android предлагает превосходный SDK, его архитектурные паттерны довольно необычны и могут легко помешать вам в процессе разработки, особенно при создании сложных приложений, которые необходимо тестировать и поддерживать в течение длительного времени. К счастью, мы можем выбрать один из нескольких архитектурных решений для решения этой проблемы.
В чем проблема?
Это сложный вопрос. Некоторые могут сказать, что нет никаких проблем с архитектурой, предлагаемой Android. Конечно, он выполняет свою работу. Но можем ли мы сделать лучше? Я твердо верю, что мы можем.
Инструменты, предлагаемые Android, с макетами, операциями и структурами данных, похоже, направляют нас в сторону паттерна Model View Controller (MVC). MVC — это прочный, устоявшийся шаблон, целью которого является изоляция различных ролей приложения. Это известно как разделение интересов .
Эта архитектура создает три слоя:
- модель
- Посмотреть
- контроллер
Каждый слой отвечает за аспект приложения. Модель реагирует на бизнес-логику , View — это пользовательский интерфейс, а Controller обеспечивает доступ View к Model .
Но если мы тщательно проанализируем архитектуру Android, особенно связь между View (действия, фрагменты и т. Д.) И Model (структуры данных), мы можем заключить, что это нельзя считать MVC. Он сильно отличается от MVC и следует своим собственным правилам. Это, безусловно, может помешать вам, когда ваша цель — создать лучшее из возможных приложений.
Если говорить более конкретно, если мы подумаем о симбиотической связи между загрузчиками и операциями или фрагментами, вы поймете, почему мы должны уделять пристальное внимание архитектуре Android. Деятельность или фрагмент отвечает за вызов загрузчика, который должен получить данные и вернуть их родителю. Его существование полностью связано с его родителем, и нет разделения между ролью просмотра (действие / фрагмент) и бизнес-логикой, выполняемой загрузчиком.
Как мы можем использовать модульное тестирование в приложении, в котором данные (Loader) так тесно связаны с представлением (Activity или Fragment), если самой сущностью модульного тестирования является тестирование наименьшего возможного фрагмента кода? Если вы работаете в команде и вам нужно что-то изменить в чужом коде, как вы можете найти проблему, если проект не придерживается известного архитектурного паттерна и что-то может быть буквально где угодно?
Каково решение?
Мы можем решить эту проблему путем реализации другого архитектурного паттерна, и, к счастью, Android SDK позволяет нам выбирать между несколькими решениями. Мы можем сузить наш выбор до решений, наиболее подходящих для Android. Шаблон Model View Controller (MVC) — хороший выбор, но еще лучше — тесно связанный шаблон Model View Presenter (MVP) . MVP был разработан с использованием тех же предпосылок, что и MVC, но с более современной парадигмой, которая создает еще лучшее разделение интересов и максимизирует тестируемость приложения.
Учитывая архитектуру Android (или ее отсутствие), мы можем сделать вывод, что:
- Android не слишком беспокоится о разделении проблем
- Лучше оставить архитектуру Android такой, какая она есть, что может привести к проблемам в будущем
- отсутствие надлежащего архитектурного паттерна может сделать юнит-тестирование настоящей агонией
- Android позволяет выбирать между несколькими альтернативными архитектурными паттернами
- Model View Presenter (MVP) — одно из лучших решений для Android
2. Модель Viewer Presenter на Android
Как я уже упоминал ранее, разделение интересов — не самая сильная сторона Android. К счастью, шаблон «Представление модели» значительно улучшает это. MVP разделяет приложение на три слоя:
- модель
- Посмотреть
- Ведущий
Каждый из них имеет свои обязанности, и связь между этими уровнями управляется докладчиком. Ведущий работает как посредник между различными частями.
- Модель содержит бизнес-логику приложения. Он контролирует, как данные могут быть созданы, сохранены и изменены.
- Представление — это пассивный интерфейс, который отображает данные и направляет действия пользователя в Presenter.
- Ведущий действует как посредник. Он извлекает данные из модели и показывает их в представлении. Он также обрабатывает действия пользователя, переданные ему представлением.
Различия между MVC и MVP
Шаблон Presenter Model View основан на шаблоне Model View Controller. Так как они разделяют несколько концепций, их трудно различить. Ведущий и Контроллер имеют сходную роль. Они несут ответственность за связь между моделью и представлением. Тем не менее, контроллер не управляет Model и View так строго, как ведущий.
В паттерне MVC слой View несколько интеллектуален и может извлекать данные непосредственно из модели. В шаблоне MVP представление является полностью пассивным, и данные всегда доставляются в представление докладчиком. Контроллеры в MVC также могут совместно использоваться несколькими представлениями. В MVP представление и докладчик имеют взаимно-однозначное отношение, поэтому докладчик привязан к одному представлению.
- В MVP представление не может получить доступ к модели.
- Ведущий привязан к одному представлению.
- Вид полностью пассивен в паттерне MVP.
Эти концептуальные различия делают то, что шаблон MVP гарантирует лучшее разделение задач, а также значительно повышает тестируемость приложения, способствуя большему разделению трех основных уровней.
Деятельность, фрагмент и просмотр объектов
Существует несколько толкований того, как MVP может быть реализован на Android. В целом, однако, действиям и фрагментам назначается роль View, и они отвечают за создание Presenter и Model. Представление также отвечает за поддержание модели и презентатора между изменениями конфигурации, информируя их о возможном уничтожении представления.
Другие объекты View, такие как RecyclerView, также могут считаться частью слоя View в MVP. Между представлением и докладчиком существует взаимно-однозначное отношение, и иногда в сложных ситуациях может потребоваться несколько докладчиков.
Что мы знаем до сих пор
- Используя архитектурные и дизайнерские шаблоны, мы можем сделать разработку намного проще и прозрачнее.
- В Android отсутствует хорошо структурированный архитектурный паттерн.
- Без использования установленных шаблонов проектирования мы можем столкнуться с рядом трудностей, особенно проблем, связанных с ремонтопригодностью и тестируемостью.
- Шаблон Model View Presenter увеличивает разделение задач и облегчает модульное тестирование.
- Докладчик обеспечивает связь между представлением и моделью.
- Представление отображает данные и направляет взаимодействие пользователя с докладчиком.
- Модель отвечает за бизнес-логику приложения.
- Роль просмотра в основном предполагается действием или фрагментом.
Вывод
В следующем уроке мы реализуем шаблон «Представление модели» на Android. Мы проверим концепции, которые мы изучили в этом руководстве, и дополнительно исследуем сложности шаблона и то, что это значит для Android.
В конце этой серии вы сможете внедрить MVP в свои собственные проекты, создать собственную платформу или принять другие известные решения. Я надеюсь увидеть вас в следующем уроке.