现在在我的项目中，我有很多服务(工厂)用于处理数据，几乎将数据保存在js数组(缓存和存储)中，并通过使用下划线处理数据来处理这些数据。
我发现在使用ngrx的angular2中有很多例子。
使用存储比较使用数据服务来处理数据有什么好处？
如果我有多种数据类型(库存，订单，客户…)，我的应用程序是否需要多个存储？
我如何构建(设计)我的应用程序来处理这样的多种数据类型？
您可以看到，Angular App是使用组件架构构建的，它会导致组件树。 OnPush在组件上意味着只有输入属性发生变化时，更改检测才会启动。例如，如果Child B为OnPush，Child A为Default，并且更改Child A内的某个内容，则Child B的更改检测器不会被触发，因为no输入属性已更改。但是，如果您更改Child B内的某些内容，则A将重新呈现，因为它具有默认的更改检测器。
关于性能和单状态树。关于这个商店的另一个优点是，你可以真正地理解你的代码和状态的变化。所以大多数Angular 1.x应用程序的现实是范围汤。这是一张来自Lukas Ruebbelke的blog post的漂亮图案：
图片显示它相当不错。来自Tero Parviainen的另一位article谈到他如何通过禁止控制器来改进他的角色应用程序。这一切都涉及范围汤和管理不断变化的状态是一个困难的。 redux动机说如下see here：
If a model can update another model,then a view can update a model,
which updates another model,and this,in turn,might cause another
view to update. At some point,you no longer understand what happens
in your app as you have lost control over the when,why,and how of
its state. When a system is opaque and non-deterministic,it’s hard to
reproduce bugs or add new features.
通过使用ngrx / store，您可以实际解决这个问题，因为您将在应用程序中获得清晰的数据流。
由于ngrx受到redux的高度启发，我会说同样的main principles适用：
>真理的单一来源
>状态是只读的
>使用纯函数进行更改
所以，在我看来，最大的好处是，你可以轻松跟踪用户的互动和理由的状态变化，因为你派遣行动和领导永远在一个地方，而简单的模型，你必须找到所有参考，看看什么变化什么和什么时候。
使用ngrx / store还可以使用devtools查看调试状态容器并恢复更改。时间旅行，我猜，是redux的主要原因之一，如果你使用普通的旧机型，这很难。
已经提到的@muetzerich的可测性也是使用ngrx / store的好处。减速器是纯功能，这些功能易于测试，因为它们采用输入并简单地返回输出，并且不依赖于功能外的属性，并且没有副作用，例如， http呼叫等
要跳到底线，我会说，不需要使用ngrx / store来做任何这些事情，但是你会受到限制(上面提到的三个原则)的束缚，它们提供了一个共同的模式，带来了不错的收益。
对你的问题：
如果我有多种数据类型(库存，订单，客户…)，我的应用程序是否需要多个存储？
不，我不建议使用多个商店。
我如何构建(设计)我的应用程序来处理这样的多种数据类型？
也许这blog post由Tero Parviainen帮助您找出如何设计您的商店。他解释了如何为示例应用程序设计应用程序状态树。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
