[译]Flutter – 使用Provider实现状态管理

这篇文章好的的地方在于它不仅讲了Flutter Provider如何管理State的，还讲述了一个Flutter App可以采用哪一种架构。这种架构是基于clean architecture和FilledStacks这两种架构原则的(这里可能理解或者表达有误，请指正)。但是文中最后采用的还是MVVM的模式。

更加重要的一点，就是本文要讲述的Provider其实就是一种widget。搭配着Consumer这个widget一起使用，达到UI = f(state)这个state变化，UI跟着变的效果。

最后，还是那句话要看原文的请到这里，文章本身有质量，而且写的不难。

正文

Flutter团队建议初学者使用Provider来管理state。但是Provider到底是什么，该如何使用？

Provider是一个UI工具。如果你对于架构、state和架构之间有疑惑，那么并不只有你是这样。本文会帮助你理清这些概念，让你知道如何从无到有写一个app。

本文会带你学习Provider管理state的方方面面。这里我们来写一个计算汇率的app，就叫做MoolaX。在写这个app的时候你会提升你的Flutter技能：

1. app架构
2. 实现一个Provider
3. 熟练管理app的state
4. 根据state的更改来更新UI

注意：本文假设你已经知道Dart和如何写一个Flutter的app了。如果在这方面还有不清楚的话请移步Flutter入门。

开始

点击“下载材料”来下载项目的代码。然后你就可以一步一步的跟着本文添加代码完成开发。

本文使用了Android Studio，但是Visual Studio Code也是可以用的。(其实VS Code更好用，译者观点)。

在MoolaX里你可以选择不同的货币。App运行起来是这样的：

打开初始项目，解压后的starter目录。Android Studio会出现一个弹出框，点击Get dependencies。

在初始项目里已经包含了一部分代码，本教程会带着你添加必要的代码，让你轻松学会下文的内容。

现在这个app运行起来的时候是这样的：

搭建App的架构

如果你没听说过clean architecture，再继续之前请阅读这篇文章。

主旨就是把核心业务逻辑从UI、数据库、网络请求和第三方包中分离出来。为什么？核心业务逻辑相对并不会那么频繁的更改。

UI不应该直接请求网络。也不应该把数据库读写的代码写的到处都是。所有的数据都应该从一个统一的地方发出，这就是业务逻辑。

这就形成了一个插件系统。即使你更换了一个数据库，app的其他部分也不会有任何的感知。你可以从一个移动端UI更换的一个桌面UI，app的其他部分也并不用关心。这对于开发一个易于维护、扩展的app来说十分有效。

使用Provider管理state

MoolaX的架构就符合这个原则。业务逻辑处理汇率相关的计算。Local Storage、网络请求和Flutter的UI、Provider这些全部都互相独立。

Local storage使用的是shared preferences，但是这个和app的其他部分没有关联。同理网络请求如何获取数据和app的其他部分也没有任何关联。

接下来要理解的是UI、Flutter和Provider都在同一个部分里。Flutter就是一个UI框架，Provider是这个框架里的一个widget。

Provider是架构吗？不是。
Provider是状态管理吗？不是，至少在这个app里不是。

state是app的变量的当前值。这些变量是app的业务逻辑的一部分，分散、管理在不同的model对象里。所以，业务逻辑管理了state，而不是Provider。

所以，Provider到底是什么呢？

它是状态管理的helper，它是一个widget。通过这个widget可以把model对象传递给它的子widget。

Consumer widget，属于Provider 包的一部分，监听了Provider暴露的mode值的改变，并重新build它的全部子widget。

使用Provider管理state系列对state和provider做了更加全面的解析。Provider有很多种，不过多数不在本文的范围内。

和业务逻辑通信

文本的架构模式受到了