0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: flutter, архитектура управления состоянием, state management system</p>
1
<p>Теги: flutter, архитектура управления состоянием, state management system</p>
2
<p>Что лучше всего выбрать при разработке первого проекта на<strong>Flutter</strong>? Можно ли просто писать код либо использовать MVC/MVVM/MVP как в том же Swift? Давайте попробуем разобраться.</p>
2
<p>Что лучше всего выбрать при разработке первого проекта на<strong>Flutter</strong>? Можно ли просто писать код либо использовать MVC/MVVM/MVP как в том же Swift? Давайте попробуем разобраться.</p>
3
<p>Раз уж вспомнили Swift, то там с выбором было проще:</p>
3
<p>Раз уж вспомнили Swift, то там с выбором было проще:</p>
4
<p>Что касается Flutter, то здесь мы подбираем не архитектурный паттерн, как таковой, с последующим построением приложения по правилам выбранного решения, а подбираем<strong>State Management System</strong>- так называемую<strong>архитектуру управления состоянием</strong>. Пришло это из области web-разработки. И вот здесь перед нами возникает следующий выбор: • Vanilla/Native state; • Provider/Scoped Model; • BLoC; • Redux.</p>
4
<p>Что касается Flutter, то здесь мы подбираем не архитектурный паттерн, как таковой, с последующим построением приложения по правилам выбранного решения, а подбираем<strong>State Management System</strong>- так называемую<strong>архитектуру управления состоянием</strong>. Пришло это из области web-разработки. И вот здесь перед нами возникает следующий выбор: • Vanilla/Native state; • Provider/Scoped Model; • BLoC; • Redux.</p>
5
<h2>Vanilla/Native state</h2>
5
<h2>Vanilla/Native state</h2>
6
<p>Иногда говорят, что лучшая архитектура - это отсутствие архитектуры.</p>
6
<p>Иногда говорят, что лучшая архитектура - это отсутствие архитектуры.</p>
7
<p>Тут все просто, то есть пишем, как есть, но в соответствии с мануалом Google. Особенности такого подхода - высокая скорость разработки, а также отсутствие разделения между бизнес-логикой и UI. Но на практике вы вряд ли сможете применить такой подход при разработке большого приложения, иначе получите проблемы с отладкой и последующим переиспользованием кода.</p>
7
<p>Тут все просто, то есть пишем, как есть, но в соответствии с мануалом Google. Особенности такого подхода - высокая скорость разработки, а также отсутствие разделения между бизнес-логикой и UI. Но на практике вы вряд ли сможете применить такой подход при разработке большого приложения, иначе получите проблемы с отладкой и последующим переиспользованием кода.</p>
8
<h2>Provider/Scoped Model</h2>
8
<h2>Provider/Scoped Model</h2>
9
<p>Здесь уже бизнес-логика вынесена из представления. В целом все предельно просто, плюс есть возможность переиспользования кода. Однако проблемы все же возможны, и начинаются они при работе с крупными и даже со средними проектами.</p>
9
<p>Здесь уже бизнес-логика вынесена из представления. В целом все предельно просто, плюс есть возможность переиспользования кода. Однако проблемы все же возможны, и начинаются они при работе с крупными и даже со средними проектами.</p>
10
<h2>BLoC</h2>
10
<h2>BLoC</h2>
11
<p>Архитектура управления состоянием BLoC (Business Logic Component) создана для управления сложными состояниями Flutter-приложений и основывается она на реактивной парадигме. Здесь тоже бизнес-логика выносится отдельно, однако тут она<strong>разбивается на разные модули</strong>. Архитектура довольно сложна для входа, зато позволяет ускорить время разработки на поздних стадиях проекта, а также уменьшить время отладки.</p>
11
<p>Архитектура управления состоянием BLoC (Business Logic Component) создана для управления сложными состояниями Flutter-приложений и основывается она на реактивной парадигме. Здесь тоже бизнес-логика выносится отдельно, однако тут она<strong>разбивается на разные модули</strong>. Архитектура довольно сложна для входа, зато позволяет ускорить время разработки на поздних стадиях проекта, а также уменьшить время отладки.</p>
12
<h2>Redux</h2>
12
<h2>Redux</h2>
13
<p>Популярное архитектурное решение, пришедшее из веба. Особенности - более жесткие ограничения и меньше свободы выбора. Но в том числе и за счет этого удается достичь свойственной для Redux гибкости и простоты отладки.</p>
13
<p>Популярное архитектурное решение, пришедшее из веба. Особенности - более жесткие ограничения и меньше свободы выбора. Но в том числе и за счет этого удается достичь свойственной для Redux гибкости и простоты отладки.</p>
14
<p>Что же выбрать? Обычно для первого проекта рекомендуют BLoC, однако на деле далеко не всегда стоит сразу так сильно углубляться в технологии, поэтому, возможно, вполне сгодится тот же Provider. Выбор, как обычно, следует делать с учетом специфики предстоящего проекта.</p>
14
<p>Что же выбрать? Обычно для первого проекта рекомендуют BLoC, однако на деле далеко не всегда стоит сразу так сильно углубляться в технологии, поэтому, возможно, вполне сгодится тот же Provider. Выбор, как обычно, следует делать с учетом специфики предстоящего проекта.</p>
15
<p><em>По материалам "<a>Дневника Flutter-разработчика</a>".</em></p>
15
<p><em>По материалам "<a>Дневника Flutter-разработчика</a>".</em></p>
16
16