**我试图了解 RepositoryProvider 的使用,我所知道的是:
BlocProvider provides bloc to its children , whereas RepositoryProvider provides repository to its children
但是我对RepositoryProvider的实际使用还是有点困惑。有人可以帮助澄清我是否理解正确吗?**
假设我想在天气应用程序中使用 flutter_bloc。当用户触发一个事件来获取特定位置的天气时,我的理解是,我们不是直接从 bloc 类中的 API 获取数据,而是触发(或调用)从 bloc 类到存储库中的方法的方法类(class)。根据获得的结果,我们将更新状态。
在这种情况下,这是 RepositoryProvider 的正确用法吗?或者有人可以提供一个简单的场景来实现 RepositoryProvider 吗?任何见解将不胜感激!”
Also if somebody could provide a simple yet detailed example of how to use 'repositoryprovider' in a weatherapp and what issues would it be simplifying.
最佳答案
你遇到的问题在学习flutter_bloc的人中很常见,我自己也遇到过。
与BlocProvider
相反,RepositoryProvider
可以提供任何类型的对象,而不是简单地说,仅提供Bloc
类型的对象。您可以在源代码中看到这一点:
class BlocProvider<T extends StateStreamableSource<Object?>>
extends SingleChildStatelessWidget ...
class RepositoryProvider<T> extends Provider<T> ...
想法是,也许有些人希望通过实现提供者设计模式来提供和访问存储库,就像 flutter_bloc
为其小部件提供 block 一样。实际上,根据我的观察,这几乎从未使用过,因为人们选择将 View 层与业务逻辑和数据层分开,因此永远不需要(甚至避免)从小部件级别访问这些存储库,如果他们需要的话可能性,他们使用服务定位器和依赖项注入(inject),例如使用 get_it
注册这些存储库,因为这对他们来说效果更好。
在您提到的示例中使用它主要是因为文档试图涵盖该包可以提供的工具的所有可能性,但这并不意味着它是该问题的最佳解决方案。尽管这是有效的解决方案,但我认为它不是最有效的解决方案。
大多数时候,对存储库的所有调用都应该仅由 block 触发,这样就不再需要从 View 层(例如构建方法)访问存储库。
关于flutter - Flutter_bloc中RepositoryProvider的实际使用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/77531335/