我正在编写一个相对简单的应用程序，我需要在其中进行一些状态管理。在查看了所有文档和许多重写之后，我需要帮助来理解如何实际构建和使用为状态管理提供的工具，例如经典提供程序和 Riverpods 提供程序。我的问题涉及保持状态的模型的排列，嵌套这些对象并仅重绘小部件树的一部分。
我的项目是一个移动应用程序，它可以让你保存你的加油站和你支付的钱的共享日志。如果您与一个或多个人共用一辆车，您将进入一个显示燃料条目的池。有用户、日志条目和池的模型。当用户登录时，需要获取并存储多个可用池，并在选择后获取所选池的成员和日志。如果对用户名或特定日志条目等进行了更新，则可能需要更新当前视图。
现在，当前代码是一团糟，其中大部分状态都存储在池模型中，该模型由ChangeNotifierProvider小部件树根处的 a 提供。由于我的印象是应该尝试尽可能少地更新 UI，因此我尝试将我的状态拆分为不同的模型，这些模型相互嵌套，例如LogEnries它们是池模型的一部分，但它们本身就是ChangeNotifier. 这个想法是能够有选择地刷新和收听部分状态。这导致了可怕的代码，我有时需要notifyListeners()从我的池模型/状态对象之外调用。我想通过重写我的状态管理来纠正这种情况。
现在我的问题是：一个结构状态一般（或我的状态）如何才能高效并取悦创建图书馆的魔法之神？这个来自两年/一年前的stackoverflow 问题提出了一个类似的问题，并且提供的答案建议执行以下操作之一：
- 将状态保持为嵌套状态并将模型彼此注入
ChangeNotifierProvider，但如果提供的对象是模型，这显然不是很好 - 将所有内容放在一个状态对象中，其提供者位于树的顶部，并且可能使用选择器仅刷新受影响的 UI 部分
- 嵌套模型，但仅提供根作为不可变对象并通过调用函数和复制内容来更新状态
我认为另一种方法是
- 使用最近发布的 Riverpod 包，并为各种需求创建许多提供程序。
现在我不知道这些方法中的哪一个更好或更有效，或者它们是否都工作得很好。我对相应方法的问题是：
我将按什么顺序嵌套它们？我直观地将池嵌套在根状态对象中，池模型中的日志条目，但依赖明智我可能不得不去 User->AppState->selectedPool->Logs，导致可能的
logEntry.selectedPool.appState.user. 感觉很奇怪。这可能有效，但我总是在一个模型中获得整个状态（在我的用例中可以说不是那么大）。可以使用
Selector来仅刷新 UI 的一部分，但我认为使用可变对象存在问题，因为Selector需要能够判断某些内容是否发生了变化。此外，据我了解，我只能使用我专门选择的东西，而不能听与我之后用于 UI 刷新的属性不同的属性。和上面一样，还有很多样板代码。
这似乎是最令人兴奋的，因为riverpod 和它的供应商看起来真的很酷。但是我会嵌套我的状态还是只在全局范围内提供所有内容，并
ref.watch()在创建方法中注入一些东西？我会为我想单独收听的每个更改创建一个新的提供程序，还是在我得到对象后弄清楚它是否更便宜？由于 Riverpod 等效于 ChangeNotifier，StateNotifier 仅具有一个值（我认为？），我会为我需要的每条重要信息创建一个新的提供程序吗？
您可能已经注意到，我尝试查找很多东西，但还没有完全弄清楚如何将所有技术转化为超出代码演示大小的实际项目。如果有人能向我解释总体上构建状态管理的正确方法，我将非常感激，哪种方法可能是我的具体情况的最佳方法，最重要的是决定反对其他方法的原因可能是什么。请毫不犹豫地指出我犯的任何错误，尽管 stackoverflow 的声誉表明这可能不是问题。如果有人想看看我的代码，有一个分支我开始致力于更好的模块化，从 AppState 模型开始并重新设计一些功能。