Архитектура Flutter проекта простым языком. Clean Arch (MVVM, DI, Bloc, Inversion of Control)

Для чего нужна архитектура?

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

Clean Architecture

Clean Architecture является одной из самых популярных архитектур в мире разработки программного обеспечения, особенно для крупных и средних проектов. Она разработана Робертом Мартином (Uncle Bob) и получила широкое распространение благодаря своей модульности, гибкости и легкости в сопровождении.

Почему же она завоевала такую популярность и симпатию среди Flutter разработчиков и не только? Вот несколько причин, почему эта архитектура столь популярна и эффективна:

Четкое разделение ответственности на слои:

• Презентационный слой (Presentation): Отвечает за пользовательский интерфейс и взаимодействие с пользователем. Здесь находятся виджеты Flutter, которые отображают данные и обрабатывают пользовательские действия. Кроме интерфейса в текущем слое находится наш менеджер состояния и view модель.

• Слой домена (Domain): Содержит бизнес-логику и правила приложения. Это сердцевина нашей фичи или приложения, которая независима от фреймворков и внешних библиотек.

• Слой данных (Data): Отвечает за управление данными, включая работу с базами данных, сетевыми запросами и кешированием.

Позже мы разберем где и какие именно папки, классы и их реализации должны находится.

Какие шаблоны проектирования нужны для чистой архитектуры?

MVVM — Model View View Model — это архитектурный паттерн, который используется для разделения логики представления (UI) и бизнес-логики в приложениях, стоит использовать только в том случае если в нашем виджете , который должен быть максимально “глупым”, существует зависимости от репозитория или же методов. Если присутствует большое количество переменных, переопределенных методов по типу initState так же нужно создать viewModel, в которую мы перенесем всю ненужную «глупому» виджету логику. Ниже нарисованная схема поможет лучше понять смысл этого паттерна.

Inversion of Control (инверсия управления) — это некий абстрактный принцип, набор рекомендаций для написания слабо связанного кода. Суть которого в том, что каждый компонент системы должен быть как можно более изолированным от других, не полагаясь в своей работе на детали конкретной реализации других компонентов.

Dependency Injection (внедрение зависимостей) — это одна из реализаций этого принципа помимо этого есть еще: Service Locator — широко известный анти-шаблон. А чем он занимается? Предоставляет доступ одних объектов к другим объектам.

Принципы ViewModel

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

Model — Модель представляет данные и бизнес-логику приложения. Она отвечает за управление данными и обеспечение согласованности и целостности приложения. В нашем случае Model будет абстрактным репозиторием из Domain слоя.
View — View отвечает за представление данных пользователю и захват пользовательских взаимодействий. Это пользовательский интерфейс, с которым взаимодействуют пользователи. Сохраняйте виджеты максимально «глупыми», минимизируя логику в компонентах пользовательского интерфейса вынося их в ViewModel.
ViewModel — это посредник между Model и View. Он содержит логику представления, раскрывая данные и команды, к которым View может привязываться. ViewModel разработан для тестирования независимо от UI. Он также часто инкапсулирует состояние View и обрабатывает ввод и взаимодействие пользователя.

Пример ViewModel:

class MapViewModel {   MapViewModel({required this.context,required this.infoLocationRepository,required this.locationRepository});   final BuildContext context;   final LocationRepository locationRepository;   final InfoLocationRepository infoLocationRepository;      late final UserLocationBloc locationBloc = UserLocationBloc(repository: locationRepository);   late final UserInfoLocationBloc userInfoLocationBloc = UserInfoLocationBloc(infoLocationRepository: infoLocationRepository);   late GoogleMapController mapController;      ValueNotifier selectLat = ValueNotifier([double]);   ValueNotifier selectLng = ValueNotifier([double]);   String styleMap = '';   get onMapCreated => _onMapCreated;   get initialize => _initialize;    void _onMapCreated(GoogleMapController controller) {     mapController = controller;   }    void _initialize() {     locationBloc.add(GetStartUserLocation());     DefaultAssetBundle.of(context).loadString('style.json').then((onValue) {       styleMap = onValue;     });   } }

Теперь наш виджет по настоящему «глупый», в нем нет реализации методов и прочего, теперь это все в нашей view model.

Структура проекта:

Utils

Utils содержит в себе все настройки и коллекции приложения. Тема, цвета нашего приложения. Коллекции с нашими svg/png картинками. Какая-то часть разработчиков называют данную папку theme.

Features

Features папка будет содержать все функции приложения, такие как аутентификация, профиль… А уже каждая фича будет разделяться на слои:

Data Layer

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

• Repositories — Здесь хранится вся реализация бизнес логики, которая имплементируется от абстрактных классов описанных в Domain.

• Models — Модельки наших ответов с сервера.

• Service — Тут хранится реализация логики обращения к API или же к БД. В моем случае я использую библиотеку Retrofit, которая не нуждается в обработке и долгой реализации, именно поэтому наш абстрактный класс будет реализован сразу в Data. Как вы видите благодаря многим инструментам мы можем отойти от строгости структурирования чистой архитектуры.

Domain Layer

Domain Layer, также известный как Business Logic или Use Case Layer, содержит основные бизнес-правила и логику приложения. Он представляет собой сердце программной системы, инкапсулируя существенную функциональность, которая не зависит от какой-либо конкретной структуры.

• Repositories — Здесь мы объявляем наши абстрактные классы, которые реализованы в data.

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

• Use_case — часто реализуются в виде отдельных классов или методов, которые инкапсулируют бизнес-логику. Это позволяет отделить бизнес-логику от деталей реализации (интерфейсы пользователя, базы данных и т.д.) и сделать код более модульным и тестируемым.

Presentation Layer

Presentation Layer (слой представления) в программировании — это слой архитектуры приложения, который отвечает за отображение данных пользователю и обработку взаимодействий пользователя с приложением. Он играет важную роль в том, как пользователи взаимодействуют с приложением и как данные и команды передаются между пользователем и бизнес-логикой.

• Bloc — У вас эта папка может называться по другому , все зависит от вашего стейт-менеджера, у меня это блок.

• Page — здесь хранятся наша верстка.

• View Model — Здесь находится модель наших экранов

• Widget — Виджеты которые дают верстке не читабельный вид и требуют вынесения в отдельные файлы (например из-за своей громоздкости).

Core

Папка core представляет собой фундаментальный модуль, содержащий ключевые компоненты, такие как утилиты, маршруты, сеть, службы, валидаторы и т. д. Часть разработчиков кучу папок суют в core, а кто-то разделяет как и features на слои: domain, data, presentation; как это делаю я и большинство разработчиков. Так легче ориентироваться и находить нужные тебе файлы.

Data:

• Storage — Описание работы с нашим хранилищем.

• Translation — наша логика перевода.

Domain:

• Di — di container в котором мы проинициализируем зависимости приложения (классы которые должны быть single ton).

• Repository — здесь хранится вся логика наших шаблонов применяемых к большому количеству реализаций. Например Dio Interceptor — настраивает все запросы (В моем случае добавляет в хедеры токен, который используется во всех запросах) или ответы. (У меня при ответе сервера 401 ошибки выполняется перезаписывание токена и повторное обращение к серверу)

• Router — тут находятся наши пути, по которым мы будем перемещаться между экранами.

• Use_case — тот же шаблон как и repository но применяемый не для самой реализации, а для обработки существующей реализации. Например шаблон ответа от сервера:

sealed class Result<T> {   bool get isSuccess;    const factory Result.data(T data) = DataResult;    const factory Result.error(List<String> errorList) = ErrorResult; }  class DataResult<T> implements Result<T> {   final T data;    const DataResult(this.data);    @override   bool get isSuccess => true; }  class VoidResult<T> implements DataResult<T?> {   @override   bool get isSuccess => true;    @override   final T? data;    const VoidResult([this.data]); }  class ErrorResult<T> implements Result<T> {   final List<String> errorList;    const ErrorResult(this.errorList);    @override   bool get isSuccess => false; }

То есть мы обрабатываем уже ответ от существующей реализации.

Presentation:

• Page — тут находятся наши базовые скрины, такие как BottomNavigation. Которые управляют навигацией всего приложения.

• Widget — тут все, часто переиспользуемые виджеты.

У чистой архитектуры нет строгих принципов. Это лишь базовые папки и подходы, которые были описаны в этой статье. В каждой компании свои подходы, но познакомившись с той структурой, что описал я, не будет никаких проблем разобраться в каком либо уже существующем проекте. Я вам гарантирую, что в core/domain не будут только те папки, сказаны мною выше. Там может находится логика обработки push уведомлений, логика входа с помощью отпечатка пальца и так далее. Каждый проект несет за собой свои особенности и фичи.

Но если вам скажут создать новый функционал, например реализовать передачу местоположения пользователя в фоном режиме, вы уже знаете что это будет описано по пути core/domain/repository и core/data/repository. В core потому это не является какой-то фичей приложения, у нее нет ui, она работает в любом месте, в любых условиях. В domain потому что у нас выполняется логика — достать место положение. Нам придется создать абстрактный класс:

abstract class Location { Location getLocation(); }

Далее в папке core/data/repository- мы уже выполняем его реализацию

class LocationImpl implements Location { @override Location getLocation(){ //code }; }

Надеюсь, эта статья была для вас полезна, желаю вам удачи ?