是角度最好的做法是将$ rootScope广播包装在自己的函数中吗？

Question

我的angularjs应用程序在很大程度上取决于$ rootScope。$ on和$ rootScope.broadcast。将$ rootScope.broadcast包装在自己的工厂中而不是直接调用$ rootScope.broadcast是否合理？ 我可以看到订阅$ on在自己的工厂中的好处，这样你就不必做$ rootScope。$ on，虽然我不确定广播。

在我的情况下，不同的指令会监听$ rootScope上的不同事件，而不是使用所有内容。 DirectiveA有自己的事件，DirectiveB可能有重叠集，DirectiveC可能有与DirectiveA和B完全不同的事件。该帖似乎建议将所有$ rootScope事件放入单个服务/“CoreReactorChannel”，如下文所述。

提示问题的原因是阅读本文： http://eburley.github.io/2013/01/31/angularjs-watch-pub-sub-best-practices.html

令我困扰的是CoreChannelReactor函数似乎是“全局的”。

在底部：“pub / sub周围的最佳实践：”它们基本上显示了与其自己的服务/工厂中的$ rootscope直接相关的所有on和广播代码。

与将rootScope直接注入多个服务，指令等相比，这种设计模式在性能或实践方面是否有任何好处？

Answer 1

在这种情况下，我不知道“最佳实践”，但这就是我们在这里所做的。 我们称之为EventBus，它支持一些额外的事情，比如拥有不同的事件通道，以避免自定义事件中的冲突，并记录在没有侦听器时广播的事件。

简而言之，它可能很有用，我推荐它。

拥有这种抽象的另一个好处是，当集中化时，您可以更轻松地更改事件系统的实现。 例如，我建议使用$ rootScope。$ emit而不是$ rootScope。$ broadcast。这样，即使不必将$ scope链级联到所有$ scopes。它只关心那些在$ rootScope级别上收听的人。

Answer 2

该模式的主要优点是巩固您对特定事件的处理。它基本上将事件源和处理程序组合到一个对象中，而不是将该逻辑分散到整个应用程序中。