Flutter：为什么 Provider 比只有静态单例的 AppGlobal 类更好？答案

【问题标题】：Flutter: Why is Provider a better option than a class called AppGlobal with only static singletons?Flutter：为什么 Provider 比只有静态单例的 AppGlobal 类更好？
【发布时间】：2023-03-08 20:54:01
【问题描述】：

据我对 Flutter 包Provider 的了解，它是一种在小部件之间共享对象的方式。我知道另一种方法是创建一个类，比如AppGlobal，并定义整个应用程序可以使用的各种static 变量。建议Provider 是一种更好的方法，但我不明白为什么会这样。

【问题讨论】：

AppGlobal 否定了依赖注入的所有好处。研究依赖注入。

标签： flutter dart flutter-provider

【解决方案1】：

通过网络快速搜索，似乎变量的全局实例并不是最好的主意，因为它不是可测试，它使代码非常耦合使用 AppGlobal 类。

这是一个链接，它描述了我在说什么，它通过示例做得很好。

Global Access vs Scoped Access with Provider

【讨论】：

为什么全局单例不可测试？我可以用一些模拟来代替它。我不必对提供给提供者的课程做同样的事情吗？耦合有什么区别？要替换全局类，我需要更改代码。如果我想更改提供给提供者的课程，是否需要同样的要求？在我看来，“提供者”的优势是“范围访问”（包括不再需要时的处置）。这样做的缺点是可读性较低，很高兴看到两种方法的性能比较。
@HajoLemcke 您在可测试性和范围访问方面是绝对正确的。然而，我在静态变量方面提到了它，它作为一个整体分布在多个文件/类中。这为更大的应用程序创建了紧密耦合的代码，并且使得创建测试场景变得更加困难。我也不反对你所说的，因为这几乎总是有利于特定开发人员编写代码的方式。在这种情况下，性能通常会被忽略，因为你会发现这两种情况几乎没有区别，除非代码写得不好。

【解决方案2】：

对问题的回答应该考虑不同的方面：

可测试性 - 差别不大。两种情况都需要代码更改以替换单例本身或“提供单身”
代码耦合 - 也没有太大的区别（见评论可测试性）
范围界定 - 单身人士最常经历整个生命周期应用。对于某些人来说，管理单身人士很容易出错小部件子树。这里提供者通过照顾肯定有其优势创建和处置。
UI 更新 - 使用单例时，必须完全手动编码 setState 会产生大量容易出错的样板代码。提供者已经在后台提供了这个。
侦听器 - 更改应用程序某一部分的状态应该通知该状态的所有消费者。对于单例，这必须手动构建。提供者已经在后台提供了这个。
延迟加载 - 默认情况下，值是延迟加载的，这意味着它们在第一次读取值时调用，而不是在第一次创建提供程序时调用。这可以通过lazy: false 禁用

希望这能更深入地回答这个问题。

【讨论】：

pt 3 是延迟加载，不是作用域，作用域可以是不同的参数