我正在使用 Angular/NGRX 开发通量应用程序。与我一起工作的一位实习生说，他使用角度服务将数据存储在他的第一个应用程序中。乍一看，这似乎是不正确的方法，但经过一段时间的考虑，我注意到它与通量存储的想法没有太大区别。
您认为这种方法的优缺点是什么？
使用 ngrx 存储、操作、reducers 等而不是使用一些 getter/setter 的普通 Angular 服务会更好吗？
谢谢！
【问题讨论】：
标签： angular design-patterns architecture flux ngrx
对我来说，区别在于方便性和一致性。
您可以轻松地将大多数 redux 原则（不变性、纯函数、可观察......）应用于 Angular 服务。因此，您可以获得与商店相同的许多好处（可预测的状态突变、可测试性、性能......）。
就方便性而言，有些好处比其他好处来得容易。例如，使用scan 操作符很容易模仿reducers，但是如果你想要在创建投影时获得的记忆（createSelector），那么这可能需要更多的工作。如果您发现自己喜欢调度操作（命令模式），那么您可以创建自己的事件总线。如果您发现自己喜欢出色的调试工具（Redux DevTools chrome 插件），那么您将不得不编写自己的集成。所以你应该看看已经用ngrx编写的工具的好处，确定你真正想要的，然后决定是否真的值得自己编写。
就一致性而言，在许多情况下，其他人将不得不处理“您的”代码。使用经过行业测试的框架有很大的好处。它可以防止你重新发明轮子（不正确地），它周围通常有很好的文档（不像你的个人框架），你可以在社区中找到已经知道它的人，或者在你遇到问题时可以支持你的人。因此，如果您发现自己走的不仅仅是编写一个简单的可观察服务，您可能需要退后一步，想想您正在创建的怪物。
此外，Redux 不仅仅是一组工具，它还是一个解决问题的思维框架。拥有这样的框架可以为整个团队的开发实践带来一致性。当存在较大的技能差距时，这一点尤其重要。在框架中，一切都有它的位置，所以你知道在哪里寻找东西。同样，您可以自己定义，只需衡量开发、教学和支持的努力。
此外，商店是全球性的。尽管您可以创建一个可观察的、整体的、上帝服务，但我希望这不是您的计划（请不要）。您可能正在创建多个较小的可观察服务。 global 有利有弊，所以这取决于你的情况，你是否认为这是一个优势。
但是使用商店也是有成本的。有很多样板（一大堆！！！）。另外，我的主要抱怨是我的消费者与我的生产者分离（商店在他们之间）。因此，我可以编写任何 rxjs 魔术，以便在需要时根据订阅 (ngrx polling to refresh data when subscribed) 管理获取数据。
所以恕我直言，一般来说，如果您只需要简单的可观察、可共享的数据，那么请使用服务。如果您需要更多，请使用商店。它在很大程度上取决于您的应用程序，但我宁愿从简单的服务开始，并在需要时将其移动到商店中。最好的建议来自它所说的 react-howto：
“你会知道什么时候需要 Flux。如果你不确定是否需要它，你就不需要它。”
延伸阅读：https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/
【讨论】：