我正在研究 angular 1.x.x 项目并考虑将我的代码升级到 angular 2 .
现在，在我的项目中，我有许多服务（工厂）来处理数据，几乎将数据保存在 js 数组（缓存和存储）中，并使用下划线处理数组来处理这些数据 .
我在angular2中使用ngrx发现了很多例子 .
What are benefits of using store compare to use data services to handle data?
Do I need multiple store for my app if I have multiple data type (stock, order, customer...)?
How can I structure (design) my app to deal with multiple data types like these?
3 回答
即使你的问题主要是基于意见的，我也可以给你一些想法，为什么ngrx是一个不错的选择 . 尽管有人说它只是一次性的，并且突变是明确的，并且在整个过程中被追踪并且通过组件进行本地维护 . 此外，您可以在应用程序中从商店中选择特定属性，因此您只能选择您关心的数据 . 如果你通过总是返回一个数组并使用Observables来接受reducers中的不变性，那么你可以使用ChangeDetectionStrategy
OnPush.OnPush为您带来不错的性能提升 . 让我们来看看官方Angular docs中的下图：如您所见，Angular App使用组件体系结构构建，从而生成组件树 . 组件上的
OnPush表示仅当输入属性发生更改时，更改检测才会启动 . 例如，如果Child B是OnPush且Child A是Default并且您在Child A内更改了某些内容，则会触发Child B's change detector won'，因为没有输入属性发生更改 . 但是，如果您更改Child B内的某些内容，则会重新呈现Child A，因为它具有默认的更改检测器 .关于性能和单状态树的重要性 . 该商店的另一个优点是，您实际上可以推断您的代码和状态更改 . 所以大多数Angular 1.x应用程序的现实是 scope soup . 这是来自Lukas Ruebbelke的blog post的精美图片：
图片展示了它非常好 . 另一个来自Tero Parviainen的article谈到了他如何通过禁止
ng-controller来改进他的Angular应用程序 . 这一切都涉及范围汤和管理不断变化的状态是一个困难 .redux动机说以下see here：通过使用ngrx / store，您实际上可以解决此问题，因为您将在应用程序中获得清晰的数据流 .
既然ngrx受到redux的高度启发，我会说同样的main principles适用：
单一事实来源
State是只读的
使用纯函数进行更改
因此，在我看来，最大的好处是，您可以轻松跟踪用户交互和状态变化的原因，因为您发送操作并且总是导致一个点，而使用普通模型，您必须找到所有引用并查看更改内容和什么时候 .
使用ngrx / store还可以使用devtools来查看调试状态容器并还原更改 . 我想，时间旅行是redux的主要原因之一，如果你使用的是普通的旧型号，那就很难了 .
@muetzerich提到的可测试性也是使用ngrx / store的好处 . 减少器是纯函数，并且这些函数易于测试，因为它们接受输入并简单地返回输出并且不依赖于函数外的属性并且没有副作用，例如， http电话等
要跳到底线，我会说不需要使用ngrx / store来做任何这些事情，但是你会受到限制（上面提到的三个原则）的限制，它们提供了一个共同的模式并带来了不错的好处 .
对你的问题：
Do I need multiple store for my app if I have multiple data type (stock, order, customer...)?
不，我不建议使用多个商店 .
How can I structure (design) my app to deal with multiple data types like these?
也许Tero Parviainen的这个blog post可以帮助你弄清楚如何设计你的商店 . 他解释了如何为示例应用程序设计应用程序状态树 .
关于使用商店的好处的一个很好的解释，你可以在那里找到documentation
Centralized, Immutable State
所有相关的申请状态都存在于一个地方 . 这样可以更轻松地跟踪问题，因为错误发生时的状态快照可以提供重要的洞察力并使重新创建问题变得容易 . 这也是一个众所周知的难题，例如在Store应用程序的上下文中撤消/重做是微不足道的，并且可以实现强大的工具 .
Performance
由于状态集中在应用程序的顶部，因此数据更新可以依靠存储片段向下流过组件 . 构建Angular 2以优化这种数据流布置，并且可以禁用变化在组件依赖于未发出新值的Observable的情况下进行检测 . 在最佳商店解决方案中，这将是绝大多数组件 .
Testability
所有状态更新都在reducers中处理，reducers是纯函数 . 纯函数非常易于测试，因为它只是输入，断言输出 . 这使得能够测试应用程序的最关键方面，而无需模拟， Spy 或其他可能使测试既复杂又容易出错的技巧 .
多家商店？
IMO使用一个商店并将您的数据类型添加为商店中的属性 .
ngrx.store可以完成设计良好的组件/服务，并带来额外的好处 . 到目前为止，我很早就开始研究它是如何结合在一起的，这就是我发现的：
通过服务和组件获得难以维护的混乱非常容易 . 如果您有级联操作，复杂数据交互和对远程位置的调用，您最终会构建一个与ngrx中的action-reducer-store排列几乎相同的服务 . 小的纯函数，可观察量等等.ngrx已经拥有它，为什么不使用它并从它所代表的思想和模式中获益 .
如果力量/鼓励在小的可测试功能中思考 . 为中等复杂的组件布置一个减速器或多个减速器，强制执行一项规则，以消除这么多小时消耗的陷阱 . 没有什么可以吞下数小时，比如追踪源于回调队列的准多线程竞争条件 . 我确信这可以通过reducers来实现，但它简化了对调用序列和调试状态的访问 .
Angular2模式变得更容易 . 具有显示逻辑的模板，组件作为模板所需的所有零碎的聚集位置 . 服务变得更简单，因为它们只是进行远程调用或处理来自任何地方的数据的io . 然后是用于维护和改变状态的动作和减速器，它触发所有其他部分响应新状态 . 我发现，对于组件/服务模式，任何一个都会变得越来越复杂，其副作用变得非常难以调试 . 我的服务最终存储状态并执行数据操作 .
观测 . 在rxjs.store中，一切都是可观察的，这是响应式应用程序的基础 . 将应用程序状态构建为可观察的有时候有点晦涩或不是非常直接，但是把它弄清楚并且做得好可以在线下进行大量的分红 .
我能看到的唯一不利因素是减速器变得非常快 . 似乎有很多情况下重复使用具有不同名称的相同代码 . 我的大脑尖叫出“带参数的功能”，但它并不是那样的 . 另一方面，这是应用程序的结构和状态以其所有细节表达的地方，因此必然会有很多 . 当出现问题时，不可避免地会出现问题，将纯函数作为问题的根源可以更容易地追踪和修复 .