Итак, это более общий вопрос. Недавно я пытался выяснить, какую архитектуру использовать с флаттером, и в итоге получил модель с ограниченным объемом, которая мне очень нравится. Но я заметил, что когда дело доходит до решения, какую информацию помещать в модели и в целом, сколько помещать в каждый файл .dart, я как бы пытаюсь понять, что происходит в темноте.
Могу ли я просто поместить туда данные, которые вызовут изменения состояния, или все, что не связано с графическим интерфейсом?
И для части общего надзора: в настоящее время я просто пишу модуль, который импортирую, и, поскольку количество строк становится слишком большим для моего вкуса (надзора), я разбиваю его на подмодули. Я чувствую, что это не лучший способ сохранить контроль и быть эффективным. Как ты с этим справляешься?
На это нет правильного ответа, вероятно, это вопрос, который следует задать на Reddit или в группе Google.
Я бы посоветовал вам не переборщить с «субмодулями» и абстракциями, если от этого нет реальной пользы, особенно на высоком уровне. Вы всегда можете сделать это позже.
Убедитесь, что ваши методы не становятся слишком длинными. Например, вы можете разделить свой метод build на buildAppBar, buildBody, buildFab. Имена методов внесут ясность в ваш код.
В целом последовательное именование очень важно.
Не бойтесь помещать несколько связанных классов и методов в один файл dart (для сравнения посмотрите исходный код Flutter).
На более высоком уровне имеет смысл отделить бизнес-логику вашего приложения от уровня виджетов. Например, избегайте смешивания кода анимации с кодом, который вызывает серверный API.
Если существует много сложной бизнес-логики или сложный уровень данных, вы можете ввести уровень услуг / данных, который состоит из простых классов (например, AccountService, WeatherDataRepository). Эти услуги будут предоставляться через InheritedWidget и работать до тех пор, пока существует приложение.