itmo_conspects

Лекция 4. Архитектура Android-приложения

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

Цель архитектуры - это уменьшение трудозатрат на создание, содержание и развитие системы

За время развития индустрии в компаниях пришли к многочисленным решениям организации кода, таких как MVC (Model-View-Controller), трехслойная или гексагональная архитектура

Позднее Роберт Мартин сформировал принцип “чистой архитектуры” (Clean Architecture):

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

Из этого следует, что бизнес-логика не должна зависеть от пользовательского интерфейса, от базы данных или другого внешнего сервиса

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

Обычно выделяют 4 слоя (от внутреннего к внешнему):

• Бизнес-правила уровня предприятия - в него включают сущностей, которыми оперирует бизнес

  Сущности - это объекты модели прикладной области. Как правило сущность представляет структуру данных с методами

• Бизнес-правила прикладного уровня - в него включают варианты использования сущностей (Use cases)

  Вариант использования (Use case) - это объект, который реализует одно или несколько конкретных бизнес-правил. Сущности не должны зависеть от вариантов использования

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

  Набор вариантов использования обычно объединяют в интерактор

• Адаптеры интерфейсов - как правило, их называются контроллерами (Controller), шлюзами (Gateway) или презентаторами (Presenter)

  Адаптеры соединяют варианты использования с внешним миром - они преобразуют данные из формата, удобного для бизнес-логики, в формат, удобных для внешних сервисов (так называемых DTO, Data Transfer Object)

• Фреймворки и драйверы - это пользовательские интерфейсы, API, базы данных и так далее

Зависимости в таком положении указываются только из внешнего слоя вовнутрь, то есть сущности и их варианты использования не должны зависеть от пользовательского интерфейса

Чтобы элементы какого-либо внешнего слоя общались между собой, они должны взаимодействовать через элемент внутреннего слоя, который имеет два интерфейса: один для запроса и другой для ответа

---

Применительно к Android-приложениям архитектуру делят на три слоя:

• Слоя пользовательского интерфейса
• Слой доменной модели
• Слой данных

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

Слой доменной модели опционален и отвечает за инкапсуляцию сложной бизнес-логики

Слой данных определяет, как приложение получает, хранит и синхронизирует данные

Пример файловой организации проекта может быть таким:

📁 src
    📁 data
        📁 remote
            📁 api
            📁 dto
        📁 local
            📁 db
            📁 dao
            📁 entities
        📁 mapper
        📁 repository
    📁 domain
        📁 model
        📁 repository
        📁 usecase
    📁 presentation
        📁 screen
            📁 main
                📄 MainActivity
                📄 MainViewModel
                📄 MainUiState
        📁 mapper

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

MVC

Архитектура MVC (Model-View-Controller) состоит из трех компонентов: модели, представления и контроллера.

• Модель хранит данные и бизнес-логику приложения
• Представление отображает данные пользователю
• Контроллер принимает действия пользователя, изменяет модель и обновляет представление

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

Преимущества MVC:

• простая и понятная структура для небольших приложений
• легко начать разработку без сложной подготовки архитектуры

Недостатки MVC:

• контроллер со временем может стать слишком большим
• код интерфейса и бизнес-логика часто смешиваются
• такой подход сложнее поддерживать и тестировать в крупных проектах

MVP

Архитектура MVP (Model-View-Presenter) разделяет ответственность между моделью, представлением и презентатором

• Модель отвечает за данные и доступ к бизнес-логике
• Представление отображает данные и передает действия пользователя
• Презентатор получает события от представления, обращается к модели и подготавливает данные для отображения

Главная идея архитектуры MVP состоит в том, что представление должно быть максимально простым, а основная логика взаимодействия переносится в презентатор. Такой подход упрощает тестирование, потому что презентатор можно проверять отдельно от пользовательского интерфейса

Преимущества MVP:

• лучшее разделение ответственности по сравнению с MVC
• презентатор удобно тестировать отдельно от пользовательского интерфейса
• представление становится проще и содержит меньше логики

Недостатки MVP:

• увеличивается количество классов и интерфейсов
• при большом количестве экранов растет объем шаблонного кода
• презентатор может стать слишком сложным, если в него переносить слишком много логики

MVVM

Архитектура MVVM (Model-View-ViewModel) особенно популярна в Android-разработке. В ней:

• Модель отвечает за данные и бизнес-логику
• Представление отображает состояние экрана и передает действия пользователя
• Модель представления (ViewModel) хранит состояние экрана, обрабатывает события и предоставляет данные для представления

В модель представления обычно помещают логику экрана, которая не должна зависеть от жизненного цикла конкретных активности или фрагмента. В Android-разработке этот паттерн часто используют вместе с типами LiveData, StateFlow или во фреймворке Jetpack Compose

Преимущества MVVM:

• хорошо сочетается с современными инструментами Android
• удобно управлять состоянием экрана через модель представления
• упрощается тестирование логики экрана
• уменьшается связность между интерфейсом и логикой

Недостатки MVVM:

• новичкам бывает сложнее понять поток данных
• при неаккуратной реализации модель представления может стать слишком большой
• использование реактивных механизмов требует дополнительного понимания

MVI

Архитектура MVI (Model-View-Intent) строится вокруг однонаправленного потока данных (Unidirectional Data Flow)

• Представление отправляет намерения (Intent) пользователя
• Модель или хранилище состояния обрабатывает их и формирует новое состояние
• Представление подписывается на состояние и полностью перерисовывается при его изменении

Главное преимущество MVI состоит в том, что состояние экрана хранится в одном месте и изменяется предсказуемо. Такой подход удобен для сложных экранов с большим количеством состояний, но может требовать больше шаблонного кода

Преимущества MVI:

• предсказуемое изменение состояния благодаря однонаправленному потоку данных
• состояние экрана хранится централизованно
• удобно отслеживать и отлаживать сложные сценарии интерфейса

Недостатки MVI:

• требует больше шаблонного кода
• может быть избыточным для простых экранов
• сложнее в освоении по сравнению с MVC или MVP

MVVM и MVI чаще всего применяются в современных Android-приложениях, потому что они хорошо сочетаются с реактивным подходом и удобны для сопровождения

This site is open source. Improve this page.