Добрый день! Разработкой монолитов и микросервисов занимаюсь давно на SQL/.NET. Flatter/Dart

начал изучать недавно. Посоветуйте хороший ресурс посвященный построению архитектуре приложений на Flatter/Dart. Пока для меня Flatter/Dart выглядит этаким зоопарком, нет единых практик и подходов. Интересует как реализовать принципы SOLID, DDD, Dependency Injection, Clear Architecture. Многие статьи которые читаю противоречат друг другу и явно указывают на индусское происхождение.
В качестве стейт системы решил выбрать BLOC, однако все описания и примеры используют 1-2 блока в системе. Попытка использовать BLOC как Mediatr в .NET не приводит к желаемому результату. Если предполагается несколько сотен блоков как реализовать взаимодействие между блоками?
Возможно не там ищу, может есть может что-то похожее на референсную архитектуру для приложений от Майкросовт?

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

Смотри в сторону MobX.dart. Это примерный аналог MVVM для натива или Vue.js, если знаком с таким. Забудь про блок. Громоздкая неудобная хренотень. И не слушай чувака с редаксом.

С MVVM не знаком. я до этого не писал фронтоые приложение. 15 лет только бек

мне bloc показался очень похожим на Mediatr библиотеку для C#. есть команты/эвенты, есть обработчики и есть ответ. Сейчас ищу как сделать милдвер для эвентов на соответствие бизнесс правилам, логирование и проверку прав.

https://vas3k.club/post/10567

Не ищи, прочитай доку по MobX, и делай как тут https://mobx.netlify.app Все кейсы покрывает. В качестве IoC возьми get_it

спасибо, посмотрю.

мввм для декларативной вёрстки нафиг не нужен, как и слушать ётунхейм чувака даже если у него шильдик админ

Каво, блок громоздкий, щитоо

Даже с версией 8.0 не сильно легче стало. Могу пояснить свою нелюбовь к блоку. Вот пример из моего проекта — блок карточек "что нового". Загружаем их при помощи кубита. Пишем сам кубит. Создаем 4 стейта: InitialState, LoadingState, DataState, ErrorState. И дальше мне понадобилось при нажатии на крестик скрывать весь блок карточек. И это в том же кубите уже сделать нельзя! Так как он только под загрузку данных. Это значит, надо написать ещё 1 кубит, в нем написать 2 стейта (VisibleState / InvisibleState), создавать его, считывать... Итого 2 кубита и 8 классов стейтов (а если блоки, то еще и ивенты написать). Насколько проще то же самое было бы в MobX сделать!

Вы же сами сказали что он для управления данных, второй кубит с визибл/инвизбл не нужен, т.к он никакими данными не управляет Здесь можно обойтись, как я и говорил ранее, ValueNotifier'ом Стейты и эвенты классами уже никто не пишет, пишут единый класс НеймБлокСтейт и НеймБлокЭвент и в них фактори с именами и параметрами стейтов

> пишут единый класс НеймБлокСтейт и НеймБлокЭвент и в них фактори с именами и параметрами стейтов Через freezed?

BLoC ещё вынуждает писать по 10 раз одни и те же стейты: Initial/Loading/Data/Error, пускай даже через freezed, все равно дублирование кода получается. В MobX уже просто есть готовая надстройка над фьючей — ObservableFuture, чтобы отслеживать её статус (pending/rejected/fulfilled).

С одной стороны, я согласен то что иметь уже готовые надстройки порой удобно, но когда ты описываешь собственноручно состояния — ты знаешь что и при каких условиях может произойти, случится ли rejected при получении например кода 401 от дата провайдера или fullfilled если у нас вернулся пустой массив Проще говоря, имея свои стейты можно так же описывать и их условия, что как я считаю, повышает flexibility

Надо будет попробовать наследовать Bloc с данными реализованными стейтами в след. проекте