经典软件体系结构风格（三） 基于事件的系统

基于事件的系统风格的思想是构建不直接调用一个过程，而是触发或广播一个或多个事件。
系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程。
这样，一个事件的触发就导致了另一模块中的过程的调用。 因此，该风格也称为隐式调用。

从体系结构上说，这种风格的构件是一些模块，这些模块既可以是一些过程，由可以是一些事件的集合。 过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。

基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构建会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道那些过程会被调用，因此， 许多隐式调用的系统也包含显示调用作为构件交互的补充形式。

支持基于事件的隐式调用的应用系统很多。 例如，在编程环境中用于集成各种工具，在数据库管理系统中确保数据的一致性约束，在用户界面系统中管理数据， 以及在编辑器中支持语法检查。 例如在某系统中，编辑器和变量监视器可以登记响应Debugger的断点事件。 当Debugger在断点处停下时，它声明该事件，由系统自动调用处理程序，如编辑程序可以卷屏到断点，变量监视器刷新变量数值。而Debugger本身只声明事件，并不关心哪些过程会启动，也不关心这些过程做什么处理。

优点：
1.为软件重用提供了强大的支持。 当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
2.为改进系统带来了方便。 当用一个构件代替另一个构件时，不会影响到其它构件的接口。

缺点：
1.构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
2.数据交换的问题。 有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。 在这些情况下，全局性能和资源管理便成了问题。
3.既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。