本文由 简悦SimpRead 转码，原文地址 codewithandrea.com
基于Riverpod的新应用架构介绍，以及与其他流行架构的比较 s......
在构建复杂的应用程序时，选择正确的应用程序架构是至关重要的，因为它允许你结构化你的代码，并在你的代码库增长时支持你的代码库。
好的架构应该帮助你处理复杂性而不妨碍。但要做好它并不容易。
- 没有架构会使你的代码整体上缺乏组织性。
- 过度的使用会导致过度的工程化，使得即使是简单的修改也很难进行。
在实践中，事情可能是相当微妙的，需要一些实践和经验来获得正确的平衡。
所以在这篇文章中，我将介绍一个基于Riverpod包的参考架构，它非常适用于Flutter应用开发。
而且我还会提供一个与其他流行架构的比较，因为我从他们那里借鉴了很多概念和想法。
现有架构概述
如果你研究这个话题，你可能会遇到诸如MVC、MVP、MVVM和Clean Architecture等术语。这些都是流行的应用程序架构，很早以前就被引入，以解决与我们今天使用Flutter所面临的类似问题。
严格来说，MVC、MVP和MVVM是设计模式，而清洁架构定义了一套规则和原则，帮助你架构任何复杂的软件系统。
虽然它们所依据的原则在今天仍然非常重要，但它们并不是为Flutter应用开发而定制的。
尽管如此，仍有许多人试图将它们引入Flutter世界，并取得了不同程度的成功。
流行的Flutter应用程序架构：Bloc和Stacked
最值得注意的是，Bloc架构已经获得了一些良好的采用，这主要归功于Bloc库的普及，它被各种大公司所采用。它是非常有主见的，给我们提供了一套严格的规则，让我们如何架构我们的Flutter应用程序（这是一件好事！）。
另一个有前途的是叠加架构，它基于叠加包，主要受MVVM启发。
它们都依赖于Provider，它是Flutter官方文档中的状态管理推荐包。
虽然Bloc和Stacked都没有什么问题，但Provider的作者创建了Riverpod包，以 "做出一些本来不可能的改进"（用他自己的话说）。
随着时间的推移，我开始欣赏Riverpod作为依赖注入和状态管理的完整解决方案的力量。所以我决定在它上面建立我自己的架构。👇
我对Flutter应用架构的看法（使用Riverpod）
在构建不同复杂度的Flutter应用时，我对应用架构做了很多实验，并对什么是好的、什么是不好的有了深刻的理解。
其结果是一个的参考架构，我在我所有的最新项目中都使用了这个架构。
由于缺乏一个更好的名字，我把它称为Riverpod架构--不过请记住，这只是我对它的看法，而不是Remi Rousselet（Riverpod的作者）认可的 "官方 "架构。
这个架构由四层组成（数据、域、应用、呈现）。
这里有一个预览。
使用数据、域、应用和表现层的Flutter应用程序架构。
这些层中的每一层都有自己的责任，并且有一个**明确的合同来规定跨边界的通信如何发生。
如果你对细节感兴趣，我正在写一系列的文章，分别涵盖每个单独的层。
- Flutter应用程序架构：存储库模式
- Flutter应用架构：领域模型
- [即将发布]: Flutter应用程序架构。应用层
- [即将到来]: Flutter应用程序架构。演示层
但现在，我只想提供一个与其他架构的有益比较。
与清洁架构的比较
清洁架构是由Robert C. Martin提出的，用这个图表示。
（洁净架构。资料来源及出处：清洁代码博客）
虽然事物有不同的名称，但我们可以确定一些类似的概念。
- 实体 → 模型
- 用例 → 服务
由于Clean Architecture被设计成独立于UI，它没有考虑到从数据源到UI的单向数据流，这是许多现代应用架构（Flutter和Web都一样）的核心设计原则。
与清洁架构的比较
相反，它使用了一个界面适配器层，包含控制器、网关和呈现器。而在Riverpod架构中，存储库属于数据层，而控制器属于表现层。
同样地，被称为框架和驱动的外层也包含了UI和DB。但这些在Riverpod架构中处于相反的两端。
这并不是说Clean Architecture不好。但我发现它增加了一些精神上的开销，我宁愿使用一个更接近我日常用于Flutter应用开发的概念模型。
与MVC比较
模型-视图-控制器（MVC）是一种由3种类型的组件组成的软件设计模式。
- 模型：直接管理应用程序的数据、逻辑和规则
- 视图。UI组件（小部件）
- 控制器。接受输入并将其转换为模型或视图的命令
MVC架构
MVC通常会给模型带来过多的逻辑负担，因此通常会增加一个额外的服务层。MVC+S。
模型应该是反应式的（例如，使用 "ChangeNotifier"），这样，当它发生变化时，小部件就会重新构建。
而用户的输入总是通过控制器，而不是直接通过模型。
与Riverpod架构相比，vanilla MVP在各层之间的通信方式上有很大不同。
与MVC架构的比较
与MVVM比较
模型-视图-视图模型（MVVM）模式的引入是为了将应用程序的业务和表现逻辑与用户界面（UI）分开。
它通常是这样表示的。
MVVM架构
当使用MVVM时，视图不能直接访问模型。
相反，视图模型处理用户的输入，并将数据从模型中转换出来，这样就可以很容易地呈现出来。
视图模型通过一个使用观察者设计模式的数据绑定与视图相连。
当从后端返回的数据不能很好地映射到你需要展示的用户界面时，拥有一个中间视图模型就特别有用。
与MVVM架构的比较
在这方面，我们很容易将MVVM与Riverpod架构进行比较。
- 视图→小工具
- 视图模型→控制器
- 模型→模型+存储库+数据源
MVVM只是一种设计模式，上图中并不包括任何数据的后期概念。
在实践中，服务和存储库被加入，以封装数据访问和缓存，使得MVVM与Riverpod架构相当相似。
与Bloc架构比较
Bloc架构页面包含这个定义了三个层次的图。
- 演示文稿
- 业务逻辑
- 数据（存储库和数据提供）。
来源和信用：Bloc Architecture
这与这里介绍的Riverpod架构是一致的。
- 展示（UI）→小部件
- 业务逻辑（Bloc） → 控制器和服务
- 数据（存储库）→存储库
- 数据（数据提供者）→数据源
主要的区别是Bloc可以依赖其他Bloc以对其状态变化做出反应，而Riverpod架构在控制器（管理小部件状态）和服务（管理应用状态）之间有更明确的区分。
注意：当使用Bloc时，状态变化总是被表示为数据流。但是Riverpod使得**观察不同种类的数据成为可能（流、期货、StateNotifiers、ChangeNotifiers等）。
总的来说，我发现Bloc架构是最接近于这里提出的方法的一种。
与堆叠式架构的比较
Stacked架构（基于Stacked包）与MVVM相似（但不完全相同），由3个主要部分组成，很容易映射到Riverpod架构中。
- 视图→小部件
- 视图模型→控制器
- 服务→服务
它还定义了一些关于你能做什么和不能做什么的规则（更多信息）。
Stacked提供了一个基础架构和一个广泛的有用的部件（如ViewModelBuilder），你可以用它来 "绑定 "ViewModel和View，使你的生活更轻松，这样你就不必重新发明轮子了。
ViewModels本身是扩展了ChangeNotifier的Dart类，它们有反应式和非反应式的变体。
主要的区别是Stacked是基于Provider的，而Riverpod架构使用Riverpod（显然😅）。
但正如我们所说，Riverpod给了我们建立一个强大的架构所需要的一切。
与Android应用架构的比较
我直到现在才提到，但Android文档中也有一个有用的应用架构指南，与我使用的架构非常相似。
Android应用架构
虽然这个架构指的是许多常见的Android组件（如活动、片段等），但这些与Flutter世界中的小工具相同，而且各层之间也有密切的匹配。
与Android应用架构的比较
在Android应用架构中，UI和数据层是始终需要的，而域层是可选的。这是因为并不是所有的应用程序都有复杂的业务逻辑，或需要被多个视图模型重用的简单业务逻辑。同样，在Riverpod架构中，如果不需要，省略应用**层也是合理的。
总的来说，我鼓励你阅读整个Android指南，因为它详细地描述了每一层的作用。
其他流行的架构
应用程序架构是基于抽象的，这些抽象使用设计模式实现，而不是API。因此，您可以在其他流行的状态管理包之上创建自己的应用架构，如redux、MobX等。
你甚至可以使用Flutter开箱即用的东西（InheritedWidget, ChangeNotifier, ValueListenableBuilder, 和朋友）。
归根结底，最重要的是你在你的应用程序中定义了明确的合同和边界。
在这方面，我非常喜欢eBay工程博客中的这句话。
我们相信，选择正确的工具或应用单一的设计模式，远不如在应用程序中的独特功能和组件之间建立明确的契约和边界来得重要。如果没有界限，就很容易写出无法维护的代码，而这些代码又不能随着应用的复杂程度的增加而扩展。
结论
正如我们所看到的，Riverpod架构与其他流行的架构有许多共同之处（也有一些不同之处）。
时至今日，我已经非常乐意在各种Flutter应用中使用它。
而且我正在写一系列的文章，更详细地介绍它。
- Flutter应用架构：存储库模式
- Flutter应用架构：领域模型
- [即将出版]。Flutter应用程序架构。应用层
- [即将到来]: Flutter应用程序架构。演示层
即将推出：完整的Flutter课程
我即将推出的Flutter课程将更深入地介绍Flutter应用程序架构，以及其他重要的主题，如状态管理、导航和路由以及测试。
如果您对此感兴趣，您可以查看课程页面或在此报名。
