本节书摘来自华章出版社《AngularJS深度剖析与最佳实践》一书中的第2章，第2.11节，作者 雪狼 破狼 彭洪伟，更多章节内容可以访问云栖社区“华章计算机”公众号查看
2.11 消息
在传统的DOM编程中，消息（message）机制非常有用，特别是消息冒泡机制，让我们不用额外的代码就可以实现“职责链”模式。但是我们要尽量摆脱DOM操作，难道这是必须使用DOM操作的场景吗？不是的，Angular中也有一种不依赖DOM的消息机制，本节中我们就对它进行详细讲解。
我们知道，Scope也被组织成了一棵树，跟DOM树具有相似的结构。Angular的消息机制就是通过scope上的几个函数实现的：
$broadcast(name, args)：向当前scope及其所有下级scope递归广播名为name的消息，并带上args参数。
$emit(name, args)：向当前scope及其所有直线上级scope发送名为name的消息，并带上args参数。
$on(name, listener)：监听本scope收到的消息，listener的形式为：function(event, args) {}，event参数的结构和DOM中的event类似。
以图2-1所示的结构的scope为例：
当我们在rootScope上调用$broadcast广播一个消息时，任何一个scope（包括rootScope）上通过$on注册的listener都将收到这个消息。当我们在scope1上调用$broadcast广播一个消息时时，scope1/scope1.1/scope1.2将依次收到这个消息。当我们在
rootScope上调用$emit上传一个消息时，rootScope将收到这个消息。当我们在scope1.1上调用$emit上传一个消息时，scope1.1/scope1/rootScope将依次收到这个消息。
当通过$emit上传一个消息时，将使用冒泡机制，比如，假设我们在scope1.1上调用$emit，我们在scope1上注册一个listener：
scope1.$on('name', function(event) {
event.stopPropagation();
});
这个stopPropagation函数将阻止冒泡，也就是说scope1.1和scope1都将正常接收到这个消息，但rootScope就接收不到这个消息了。
有时候，用消息机制和普通回调函数都能达到类似的效果，如何选择呢？
当一个嵌套结构具有树形的业务含义时，我们就优先使用消息机制来通讯。或者从另一个角度看，符合“职责链”模式的适用场景时，消息机制比较合适。反之，应该使用普通的回调函数。
如果难以决定使用消息还是回调函数，那么就优先使用回调函数（主要是Angular事件），因为这种情况下执行路径比较明确，容易跟踪。或者在对此有深入理解前，先使用表面的判断方式：一个事件是否需要被很多地方处理？调用stopPropagation是否有意义？如果是，那么用消息，否则用回调。
