Выбираем архитектуру для Flutter-приложения
Что лучше всего выбрать при разработке первого проекта на Flutter? Можно ли просто писать код либо использовать MVC/MVVM/MVP как в том же Swift? Давайте попробуем разобраться.
Раз уж вспомнили Swift, то там с выбором было проще:
Что касается Flutter, то здесь мы подбираем не архитектурный паттерн, как таковой, с последующим построением приложения по правилам выбранного решения, а подбираем State Management System — так называемую архитектуру управления состоянием. Пришло это из области web-разработки. И вот здесь перед нами возникает следующий выбор: • Vanilla/Native state; • Provider/Scoped Model; • BLoC; • Redux.
Vanilla/Native state
Иногда говорят, что лучшая архитектура — это отсутствие архитектуры.
Тут все просто, то есть пишем, как есть, но в соответствии с мануалом Google. Особенности такого подхода — высокая скорость разработки, а также отсутствие разделения между бизнес-логикой и UI. Но на практике вы вряд ли сможете применить такой подход при разработке большого приложения, иначе получите проблемы с отладкой и последующим переиспользованием кода.
Provider/Scoped Model
Здесь уже бизнес-логика вынесена из представления. В целом все предельно просто, плюс есть возможность переиспользования кода. Однако проблемы все же возможны, и начинаются они при работе с крупными и даже со средними проектами.
BLoC
Архитектура управления состоянием BLoC (Business Logic Component) создана для управления сложными состояниями Flutter-приложений и основывается она на реактивной парадигме. Здесь тоже бизнес-логика выносится отдельно, однако тут она разбивается на разные модули. Архитектура довольно сложна для входа, зато позволяет ускорить время разработки на поздних стадиях проекта, а также уменьшить время отладки.
Redux
Популярное архитектурное решение, пришедшее из веба. Особенности — более жесткие ограничения и меньше свободы выбора. Но в том числе и за счет этого удается достичь свойственной для Redux гибкости и простоты отладки.
Что же выбрать?
Обычно для первого проекта рекомендуют BLoC, однако на деле далеко не всегда стоит сразу так сильно углубляться в технологии, поэтому, возможно, вполне сгодится тот же Provider. Выбор, как обычно, следует делать с учетом специфики предстоящего проекта.
По материалам "Дневника Flutter-разработчика".
