我们先看 Angular 里一个常规的使用 Ngrx Store 的例子:

上面这段代码的缺陷是,Component 作为 UI 的展现层,直接依赖于作为第三方库的 Store API —— 一个合乎逻辑的措施是,将这个逻辑通过 facade 服务的思路,抽取到一个 service 中,以保护 Component 免受库弃用或破坏性更改(breaking changes)的影响。
在 Angular 14 之前,我们可以将上面的代码进行重构,把 Store 相关的操作,封装到一个 facade service 里:

虽然重构之后代码行数变多了,但是这种设计对 breaking changes 能够应对自如,因为我们现在只需要在一个地方管理代码,即 EntityFacade,而不是重构之前在 Component 里使用 Store 的任何地方。
现在让我们看看 inject() 方式。

有一种观点认为,使用闭包需要将返回的函数存储在 Component 的属性中,这增加了 Component 的复杂性,还不如使用构造函数注入和服务。
到底使用 inject 还是传统的构造函数注入方式,取决于团队制定的编程规范。
网友评论