共计 463 个字符，预计需要花费 2 分钟才能阅读完成。
咱们先看 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 还是传统的构造函数注入形式，取决于团队制订的编程标准。
正文完
