英文:
What is an efficient Flutter architecture pattern for personal development?
问题
我已经使用Flutter工作了大约两年，目前正在寻找一个与我的个人开发需求相匹配的架构模式。我特别寻找一个优先考虑以下内容的模式：
- 最小的代码量
- 清晰的合同和边界
- 单向数据流
- 可重用性
- 可测试性
- 可维护性
我已经探索了几种架构，但出于以下原因还没有决定使用其中任何一种：
MVC： 我发现模型的角色有点不清晰，这导致我排除了它。
Bloc： 尽管我认识到Bloc在大型团队环境中具有潜力，但我观察到像Riverpod这样的替代方案显着减少了代码量，使Bloc在我的个人开发工作中不那么吸引人。
Clean Architecture和DDD： 我遇到了太多的样板代码，对于个人开发来说感觉有点多余。因此，我决定不使用这种架构。
我正在寻找一个合适的架构模式的建议，最好能够满足我的需求。提前感谢您的建议和见解。
英文:
I've been working with Flutter for about two years and I'm currently searching for an architecture pattern that aligns well with my individual development needs. I'm particularly looking for a pattern that prioritizes the following:
- Minimal code volume
- Clear contracts and boundaries
- Unidirectional data flow
- Reusability
- Testability
- Maintainability
I've explored several architectures but haven't settled on any of them for the reasons I've mentioned below:
MVC: I found the role of the Model a bit unclear, which led me to rule it out.
Bloc: Despite recognizing Bloc's potential strength in a large team context, I observed that alternatives like Riverpod significantly reduce the volume of code, making Bloc less attractive for my individual development work.
Clean Architecture & DDD: I encountered too much boilerplate code which felt excessive for individual development. Thus, I decided against using this as well.
I am seeking recommendations on a suitable architecture pattern that would best fulfill my requirements. Thank you in advance for your suggestions and insights.
答案1
得分: 2
我仍然相当确信，我的策略对我最近开发的应用程序运作良好：
- 视图
- 屏幕
- 面板
- 杂项
- 应用程序，主要作为 Riverpod 堆栈，用作：
- 应用状态（可观察的、可变的模型数据块作为状态）
- 服务（持有引用和其他状态，将对象作为状态返回）
- 单例（持有引用，将对象作为状态返回）
- 存储库（持有引用，将内部 API 对象作为状态返回）
- DTO 层（无状态，只在领域数据和外部数据之间进行转换）
- 外部 API
- 核心（任何共享的内容，如类型）
这在某种程度上基于我在 Reso Coder 的 DDD 中看到的层次结构，与我与 Riverpod 大量工作所了解的内容混合在一起。几乎所有内容都包含在 Riverpod 包装器中，以充当服务定位器 并且 在测试期间启用通过覆盖进行模拟。
通过使用 family providers（如果提供者相同但具有不同的生命周期）或使用混合类（为相关的 Notifiers 提供类似的行为），在应用程序层中重复使用代码。
英文:
I'm still pretty certain that my strategy is working well for my recent developed apps:
- view
- screens
- panes
- misc
- app, mostly Riverpod stacks serving as:
- appstate (observable, mutable chunks of model data as state)
- services (holding ref and other state, returning object as state)
- singletons (holding ref, returning the object as state)
- repos (holding ref, returning the internal API object as state)
- DTO layer (no state, just transforms between domain data and external)
- external APIs
- core (anything that's shared, like types)
It's based loosely on the layers I've seen in Reso Coder's DDD, mixed with what I know from heavily working with Riverpod. Nearly everything is inside a Riverpod wrapper, to serve as a service locator and to enable mocking-by-overrides during testing.
Code is re-used in the app layer through the use of family providers (if the providers are identical, but have distinct lifecycles), or the use of mixin classes (to give similar behavior to related Notifiers).
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论