架构推荐和资源

关注点分离是最重要的架构原则。数据层将应用程序数据暴露给应用程序的其余部分，并包含应用程序的大部分业务逻辑。UI 层显示应用程序数据并监听用户的事件。UI 层包含用于 UI 逻辑和小部件的单独类。

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

关注点分离是最重要的架构原则。这种特定的分离使您的代码更不易出错，因为您的小部件保持“哑”状态。

ChangeNotifier API 是 Flutter SDK 的一部分，是一种方便的方法，可以让您的 Widget 观察 ViewModel 中的更改。

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

逻辑应封装在 ViewModel 上的方法中。视图应包含的唯一逻辑是

• 简单的 if 语句，根据 ViewModel 中的标志或可为空字段来显示和隐藏小部件
• 依赖于小部件来计算的动画逻辑
• 基于设备信息（如屏幕尺寸或方向）的布局逻辑。
• 简单的路由逻辑

只有当您的应用程序具有超出 ViewModel 范围的复杂逻辑，或者您发现自己在 ViewModel 中重复逻辑时，才需要领域层。在非常大的应用程序中，用例很有用，但在大多数应用程序中，它们会增加不必要的开销。

在具有复杂逻辑要求的应用程序中使用。

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

Commands 可以防止应用程序中的渲染错误，并标准化 UI 层将事件发送到数据层的方式。请阅读架构案例研究中的 Commands。

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

您可以使用软件包来帮助在数据模型中生成有用的功能，freezed 或 built_value。这些可以生成常见的模型方法，如 JSON ser/des、深度相等性检查和复制方法。如果您的模型很多，这些代码生成包可能会为您的应用程序增加大量的构建时间。

使用单独的模型会增加冗长性，但可以防止 ViewModel 和用例中的复杂性。

在大规模应用中使用。

依赖注入可以防止您的应用程序拥有全局可访问的对象，这使得您的代码更不易出错。我们建议您使用 provider 包来处理依赖注入。

Go_router 是编写 90% Flutter 应用程序的首选方法。有一些特定的用例 go_router 无法解决，在这种情况下，您可以使用 Flutter Navigator API 直接使用或尝试在 pub.dev 上找到其他软件包。

我们建议根据它们所代表的架构组件来命名类。例如，您可能有以下类

• HomeViewModel
• HomeScreen
• UserRepository
• ClientApiService

为了清晰起见，我们不建议使用可能与 Flutter SDK 中的对象混淆的名称。例如，您应该将共享小部件放在名为 ui/core/ 的目录中，而不是名为 /widgets 的目录中。

仓库类是应用程序中所有数据的真相来源，并促进与外部 API 的通信。创建抽象仓库类允许您创建不同的实现，这些实现可用于不同的应用程序环境，例如“开发”和“暂存”。

• 为每个服务、仓库和 ViewModel 类编写单元测试。这些测试应单独测试每个方法的逻辑。
• 为视图编写小部件测试。测试路由和依赖注入尤为重要。

模拟对象不像它们那样关注任何给定方法的内部工作原理，而是关注输入和输出。如果您在编写应用程序代码时牢记这一点，您将被迫编写模块化、轻量级的函数和类，这些函数和类具有明确定义的输入和输出。