架构建议与资源

关注点分离是最重要的架构原则。数据层向应用的其余部分暴露应用数据，并包含应用中的大部分业务逻辑。 UI 层负责展示应用数据，并监听来自用户的事件。UI 层为 UI 逻辑和 widget 分别使用独立的类。

仓库模式是一种软件设计模式，它将数据访问逻辑与应用的其余部分隔离开来。它在应用的业务逻辑与底层数据存储机制（数据库、API、文件系统等）之间创建了一个抽象层。在实践中，这意味着创建 Repository 类和 Service 类。

关注点分离是最重要的架构原则。这种特定的分离能大幅降低代码出错的概率，因为你的 widget 始终保持「被动」（即不含逻辑的 dumb widget）。

ChangeNotifier API 是 Flutter SDK 的一部分，它提供了一种便捷的方式，让你的 widget 观察 ViewModel 中的变化。

处理状态管理的选项很多，最终的决定取决于个人偏好。阅读 我们对 ChangeNotifier 的推荐 或 其他流行选项

逻辑应当封装在 ViewModel 的方法中。View 唯一应当包含的逻辑是：

• 根据 ViewModel 中的标志位或可空字段来显示或隐藏 widget 的简单 if 语句
• 依赖 widget 才能完成计算的动画逻辑
• 基于设备信息（如屏幕尺寸或方向）的布局逻辑
• 简单的路由逻辑

只有当你的应用拥有极其复杂的逻辑、以致 ViewModel 变得臃肿，或者你发现自己在多个 ViewModel 中重复编写相同逻辑时，才需要领域层。在超大型应用中，use-case（用例）很有用，但对大多数应用而言，它们只会带来不必要的开销。

适用于具有复杂逻辑需求的应用。

数据更新应当只从数据层流向 UI 层。 UI 层中的交互会被发送到数据层进行处理。

Command 能防止应用出现渲染错误，并统一 UI 层向数据层发送事件的方式。你可以在 架构案例研究 中进一步了解 Command。

不可变数据对于确保任何必要的变更只发生在恰当的位置（通常是数据层或领域层）而言至关重要。由于不可变对象在创建后无法被修改，你必须创建一个新的实例来反映变更。这一过程可以防止 UI 层中的意外更新，并支持清晰的单向数据流。

你可以借助一些 package 来为数据模型生成实用的功能，比如 freezed 或 built_value。它们可以生成常见的模型方法，例如 JSON 序列化/反序列化、深度相等性检查以及 copy 方法。如果你的模型数量众多，这些代码生成 package 可能会显著增加应用的构建时间。

使用相互独立的模型会增加一些冗余代码，但能避免 ViewModel 和 use-case 变得复杂。

适用于大型应用

依赖注入可以避免应用中出现可全局访问的对象，从而降低代码出错的概率。我们推荐你使用 provider package 来处理依赖注入。

对于 90% 的 Flutter 应用，go_router 都是首选的编写方式。 go_router 无法解决某些特定的使用场景，这种情况下，你可以直接使用 Flutter Navigator API，或者尝试 pub.dev 上的其他 package。

我们推荐根据类所代表的架构组件来为其命名。例如，你可能会有以下这些类：

• HomeViewModel
• HomeScreen
• UserRepository
• ClientApiService

为了清晰起见，我们不推荐使用容易与 Flutter SDK 中的对象混淆的名称。例如，你应当把共享的 widget 放在名为 ui/core/ 的目录中，而不是放在名为 /widgets 的目录中。

Repository 类是应用中所有数据的可信来源 (source of truth)，并负责与外部 API 进行通信。创建抽象的 Repository 类让你可以编写不同的实现，以适配不同的应用环境，例如 development（开发）和 staging（预发布）。

fake 对象关注的并不是某个方法的内部实现，而是它的输入和输出。如果你在编写应用代码时牢记这一点，就会促使自己写出模块化、轻量的函数和类，并具备定义良好的输入与输出。