我应该如何在 Flutter 中管理大型模型的状态？

Question

我正在编写我的第一个 Flutter 应用程序，并正在努力应对各种状态管理解决方案。我决定从 Provider 开始，但我正在考虑切换到 BLoC。到目前为止，我发现的大多数示例都仅限于相对简单的事情，例如显示项目列表或响应某些按钮按下。就我而言，几乎所有应用程序都专注于设置相当大的数据块。（它基本上是一大堆表单，所有表单都在大型数据结构的不同位上工作。）

目前，所有状态管理都被放在一个提供程序类中，因为其中大部分都非常密切相关。例如，它的最大部分是一个项目列表，然后是该列表的一堆子集。应用程序中的大部分数据操作都在这些子集上。

我一开始并没有真正打算这样做，但我发现自己将实际使用提供程序的代码放在非常接近顶层的位置，然后沿着树传递数据。它违背了 Provider 的初衷，但它减少了重复的代码。例如，我的应用程序中的一个屏幕有一堆卡片，它们都包含非常相似的列表。它们之间的主要区别在于它们的内容来自不同的列表。因此，为了减少重复的代码，我尽可能地概括了卡片和列表，并将必要的数据沿树向下传递。我还传递回调函数来处理诸如编辑项目或将其从列表中删除之类的事情。

这听起来是一个不错的方法吗？事实上，我在树上传递状态和回调对我来说就像一种代码味道，但正如我所提到的，它减少了重复的代码。如果我有一个提供者暴露了很多东西，那又如何呢？我觉得我应该将数据模型与提供者分开，然后拥有多个较小的提供者。如果我要走这条路，BLoC 会比 Provider 更合适吗？如果我能够分解单一提供商，是否可能会提高性能？拥有多个提供商或集团似乎会使保存更改变得复杂，但也许并非如此。你有没有发现这是一个问题？

编辑：我刚刚发现这个问题，它讨论了不同数据的重用提供程序：Flutter Provider。如何拥有同一提供者类型的多个实例？

我以前并没有真正这么想过，但这是我正在努力解决的一个重要问题。我有独立修改的不同列表。它是在多个地方使用的相同小部件（有时在同一屏幕上），并且如果我将所拥有的内容分解成更小的部分，则提供程序中的功能也将是相同的。由于 Provider 是基于类型而不是实例，因此在这种情况下它可能不起作用。

Answer 1

我的第一个 Flutter 应用程序使用了一个 Provider 类，它可以工作，但它是一个巨大而混乱的类，并触发了大量的 UI 更新。

目前，我使用“models”文件夹作为数据模型，使用“services”文件夹作为提供者单例。

模型拥有我所有的数据类以及实用程序和变异器方法。例如，用于保存值的 MyCard 类加上用于序列化的 MyCard.fromJson() 和 .toJson()，可能还包括一些例程，例如clear() 和 validate()。

服务是我将提供者创建为单例的地方。例如，一个class MyCardService with ChangeNotifier单例可以List<MyCard>保存所有 MyCard。如果我希望 UI 小部件根据更改进行更新，例如当 MyCardService().loadCardsFromNetowrk() 完成时，我可以使用 Providerwatch或select. 如果我想访问 build() 链之外的数据，我可以使用单例模式访问它：MyCardService().myVariable。这消除了在 build() 链之外进行上下文查找的需要。

这为异步访问提供了很多控制。例如，您可以在 get 和 set 方法上使用互斥体，Future<bool> isInitialized在服务尝试初始化后解析为 true 或 false。您可以在任何需要访问服务或 FutureBuilder() 的异步调用中等待这个 future

我还有一些非提供商服务单例，其他服务将其用于网络 API 访问和文件系统缓存等内容。

提供者服务主要是按 UI 数据消耗来组织的。这样，notifyListeners() 就不会触发未修改的小部件的 UI 重建（我的第一个单文件提供程序项目的一个主要问题是使用 select 而不是一个监视产生了一堆单独的变量）。

在上面的示例中，Provider 单例包含一个 List 以及用于处理 List<> 的所有方法。MyCard 数据模型包含在 MyCard 上工作的所有方法。当我有一个编辑单个 MyCard 的小部件时，我使用一个有状态小部件，该小部件在编辑完成时执行 MyCardService().save(myCard) 。这也有助于隔离 UI 树重建。