Event-Listerner事件监听模式

事件监听模式其实就是一种观察者模式，只是角度有点不同，在Java的JavaBean机制以及GUI中都使用了事件监听模式。在如今AJAX RIA客户端中，事件监听模式也成为一个主要的界面模式。

事件监听模式分同步和异步两种实现方式，JavaBean机制和GUI基本都是同步机制，事件监听异步模型，需要引入Event Queue。

事件监听同步模式分两个部分：Event Source和Event Listener：
Event Source：被监听者的事件集合，可能是方法，提供事件的注册加入和移除功能。类似被观察者的集合。
Event Listener：事件的监听者，当事件被触发，所有监听这个事件的监听者将被通知，然后执行自己的Action响应动作。

事件监听异步模式在Source和Listener之间引入event queue，
event queue是一个基于事件的publish-subscribe. 它一种松耦合方式提供不同模块和角色之间异步通讯。它比同步更加松耦合，这样，我们就把Source-Listener改成了publish-queue-subscribe方式。

事件监听模式使用在客户端RIA比较多，因为这里是用户输入的源头，是事件发生的源头。而且在目前WOA趋势下，事件监听模式不能只单独局限于RIA客户端这个范围，还需要把事件通过http形式传递到服务器端，也就是跨客户端和服务器的，事件必须和服务器的PUSH异步结合在一起。这是一种先进的架构设计。

基于Javascript的ZK 5 RIA已经实现了这种先进的事件监听模式，见：
http://docs./wiki/ZK_5:_Chat_with_Event_Queue#Event_queues_and_server_push

如果将这种异步的事件模式和服务器的OSGI结合，那么在服务器端更新一个Jar模块，可以主动通知到客户端浏览器，
这对服务器端模块管理很有好处。
http://bundle-exception./2009/07/zk-on-osgi-dynamic-asynchronous.html

bloodrate 

记得在Header First设计模式中，MVC被看成一种复合设计模式，是策略模式和观察者模式的有机组合（很多其他文献中把MVC层看成一种架构风格），其谈到MVC设计CS的时候可以严禁的实现策略模式和观察者模式，但是MVC面对BS时候尤其是现在主流框架在jsp/servlet上没法支持观察者模式，因为你不可能把jsp注册为model的观察者，所以jsp/servlet一直从根据上不支持push，以至于主流push技术都需要客户端首先发起请求“我需要接下来的一段时间里你每10面更新一次新闻”，之后才可以开启push。
所以我在考虑是不是可以基于freemaker封装一个模板，然后摒弃jsp，而实现自己可注册监听的服务页技术呢？

banq 

严格来说：MVC模式是一种同步机制，MVC的Controller是Mediator模式，而Mediator模式的特点和缺点就是封装通讯，而Observer模式则是分离通讯。

实践证明：象Observer这种分离通讯的做法是符合可伸缩性要求的，而Mediator模式这种封装通讯是不可伸缩的。

所以，可以说MVC模式是不可伸缩的，所以，才有REST替代一说，也可以在MVC中引入事件模式。ZK5的设计就是这种基于MVC模式基础上的事件异步架构。

所以，现在只是使用一个MVC的Web框架已经远远不满足伸缩性要求。

说得不客气的话：现在所有的基于MVC框架，如Struts 2或Webwork JSF Wicket，如果不在其上引入异步事件框架，都是不合格的，都是落后的技术。

bloodrate 

> 现在所有的基于MVC框架，如Struts 2或Webwork JSF Wicket，如果不在其上引入异步事件框架，都是不合格的，都是落后的技术。

我觉得这些MVC框架不支持异步是因为其基于jsp/servlet封装起来的，servlet2.x 全都不支持异步，底层都不支持，指望上层架构如何能实现？所以要么等servlet3.0规范为大多数应用服务器实现之时，要么干脆摒弃jsp/servlet和主流servlet容器，用mina封装通讯，第三方包解析http，freemaker定制页面模板，实现真正的异步。

banq 

>干脆摒弃jsp/servlet和主流servlet容器，用mina封装通讯
这才是最灵活 最伸缩的好办法，也是我目前推崇的。