改进clean arch有多难？我已经看到很多 Flutter 开发人员采用了Flutterando 的 Clean Architecture Proposal
在不同团队中完成了多个具有干净架构的项目后，我注意到采用一些不言而喻的做法可以增强开发过程。
介绍
Clean arch 是 Robert C.（Bob 叔叔）Martin 编写的 Clean Code Book Series 中提出的一系列概念。所有人都欢呼这个人！
至少本系列的第一本书（Clean Code）是所有开发人员的“必读”书籍。
Flutterando 的提案利用干净的代码概念在 Flutter/Dart 环境中生成可扩展的编程代码。将系统分为 4 层：Presenter、Domain 、 Infra和External。
解释架构不是我的重点。因此，如果需要更多相关知识，请单击此处。
每个Widget一个Controller
在展示层，我们有Widget和Controller。控制器是我们的Widget状态管理类。并且您希望这种分离不会收集界面呈现和界面逻辑。
独立于您使用的状态管理工具，控制器应该只包含有关Widget状态管理的信息。
这里要强调的做法是避免每个Widget有多个控制器。
例如，在一个项目的初始阶段，通常你需要一个用户注册表单和一个用户编辑表单，它们具有相同的字段和规则。
这些形式之间的区别在于字段的初始值和调用的端点。有很多开发人员会为这里的每种情况创建一个带有标志的控制器。
它确实可以完成工作，但对于专业人士来说还不够。这些形式可以/倾向于不对称地改变它们的界面。 让我们在不久的将来膨胀我们的代码，不尊重单一责任原则。
你想让我在我的代码上使用 Ctrl+C Ctrl+V 吗？好吧……是的！ 避免重复很重要，但 SRP、可读性和可维护性也很重要。您需要权衡取舍。
小心！ 也有例外，例如，如果您正在创建一类必须遵循相同逻辑的小部件，例如 AnimationController和内置的隐式动画小部件。
控制器只看到Widget需要什么
继续我们关于控制器的讨论，清晰的架构将小部件逻辑（控制器）和业务逻辑（用例）的概念分开。
这意味着控制器应该只能访问与其Widget相关的信息。
例如，在特定的更改密码表单上只有 2 个字段。密码并确认密码。但是我们的端点还需要当前用户的 ID。
由于此 ID 在表单上不可见，因此控制器不应该知道它。getUserId逻辑必须在 Usecase 或 Repository 中。但要确定你在做什么。
仅在用例上强制进行错误处理
为了强制表示层处理失败场景，建议使用Dartz 库中的 Either 类或结果库中的 Result 类。
但是在专业的应用程序上，一个简单的登录操作可以通过几个步骤来执行。例如：
- 调用登录端点
- 在本地保存用户名以便下次自动填写登录表单。
- 在本地保存身份验证令牌以保持用户登录
这是我们的业务逻辑，因此应该包含在 Usecase 类中。失败可能发生在这里。这意味着用例可以使用“ throw ”关键字。
如果 Usecases 依赖项，即存储库和服务，也返回 Either/Result 值，错误处理会扰乱可读性，并且函数比它需要的更大。
Drivers很危险！从他们开始。
直觉上我们应该开始在领域层开发一个新特性。但对我来说，牢记快速失败原则效果更好。
关于开发一个新功能……哪里最有可能表现出新内容的不可行性？ 答案是：你无法控制的地方。
您对 Presenter 和 External 层的控制较少。
Presenter 受到 Flutter 框架能力的限制，但凭借强大的 Google 开发团队和快速更新，它现在非常可靠，尤其是对于移动应用程序。通常，我们不会在这里找到任何使项目不可行的东西。
外部层是与我们项目所需的所有库和 API 的通信。它的大部分内容是由不知名的人在没有监督的情况下创建的。
您要添加到项目中的库可能包含与您的项目冲突的过时文档和依赖项。
在开始一项新功能之前，请确保您拥有功能正常的驱动程序。如果出现问题，那应该在您的第一步发生。
结论
尽管 Flutterando 对 Flutter 开发的提案做出了令人印象深刻的贡献，但这并不意味着我们无法进一步改进。
我们是了解项目必要性的人。我们有责任寻找能够为我们的客户和团队成员带来更多价值的概念、原则和实践。
我只是展示其中一些对我有用的。您不应将这些视为规则，而应视为建议。告诉我它们对你是否有意义。
