Java的事件模式是动态响应系统重要的基础，在图形界面领域的事件模式已经有很多文章介绍，但是在服务器端我们会碰到更多的事件模式，这里本人试图总结一下： 事件直接驱动模式
事件模式的第一个要求就是性能的要求，需要直接而且快，Command模式是必须经常使用的，主要适合于迅速处理 前台的命令，Command模式往往是系统架构的重要部分，也是流程控制的主要模式。 Command模式经常Java的Reflect一起使用，因为系统的事件处理系统是处于动态变化的，随着功能要求扩展，就可能有动态变化事件处理响应系统，以Struts中action为例，我们知道，Structs的一个主要配置文件是struts-config.xml 如下： ＜struts-config＞
＜action-mappings＞
＜action path="/login" type="com.javapro.struts.LoginAction"/＞
＜action path="/logout" type="com.javapro.struts.LogoutAction"/＞
＜/action-mappings＞
＜/struts-config＞ |
它实际是个command和event的映射关系，通过这个配置文件，运行时动态装载相应的Action，完成Command模式， 我们检查LoginAction代码，就可以看出Command模式的基本特征： public final class LoginAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form, HttpServletRequest request, HttpServletResponse response)
throws Exception {
.................
}
} |
很明显，典型的Command模式需要有一个接口.接口中有一个统一的方法，这里统一的方法就是execute; 比如我们有个实时系统，客户段向服务器发出不同编码代号，意味着不同的请求，不同的请求有不同的Handler进行 处理，Handler接口是: public class Handler{ public byte[] handleRequest(); } |
不同性质的处理过程继承这个Handler接口，如负责进入系统的处理过程 public class EnterHandler implements Handler{ public byte[] handleRequest(){
//具体业务处理
......
} } |
调用Handler时是: //从cache中获取这个requestId对应的Handler
Handler handler = (Handler)cache.get(new Integer(reqId));
//调用handler的统一方法handleRequest()
byte[] outInf = handler.handleRequest(); |
以上是常用的一个事件驱动模式。它的特点是靠一个事件直接启动对应的事件处理器。 Chain of Responsibility职责链模式也应该属于这类，当事件到达后，让这个事件在我们提供的一批处理器中逐个挑选适合的处理器进行处理，这个模式缺点是显然的，性能丧失在逐个挑选 上，一般不推荐使用，这个模式适合在我们无法预知发生的事件内容时使用，因为不知道发生事件的具体情况， 我们就无法在程序运行前事先为其指派相应的处理器，只能靠运行时，事件自己去摸索“撞运气”。 监控式事件模式
监控式事件模式就不同于事件直接驱动模式，它是借助第三者来监控和触发事件，这类事件的特点是： 有一个观察者置身事外在定期独立运行着，我们将我们要监听的事件向这个观察者注册，这样观察者就 代替我们来监听这个事件，应用客户端通过观察者来获得事件状况。 应用客户端有三种与观察者交互的方式：1.直接融合 2.推方式 3.拉方式。 直接融合就是说应用客户端自己就是观察者，两者融合，这样无疑应用客户端获得的触发时间是最快的。 推方式就是观察者一旦侦测到事件发生，立即将事件Push推到应用客户端；拉方式类似收取邮件，应用客户端在需要时才从观察者拉取事件。 JDK 1.4的None Blocking I/O是监控式事件模式的典型实现，Selector显然是一个监控I/O的第三者，当有外部事件进来，通过 调用Slector.select方法可以获得外部事件，从而进行处理，可参考我的本栏文章。 监控式事件模式适合使用在触发性质的场合，比如数据库后端触发器 界面触发 I/O触发 状态改变触发等。 我们以一个信件触发为例，这其实是个Observer应用例子: 比如用户提请服务器计算一个数据，如果用户同时要求将计算结果向自己信箱发一封，那么我们看如何设计？按照通常思维，这是一个次序问题，先在内存中计算数据，然后将结果发送到他的信箱，最后返回结果到用户端，我们知道信件的发送是耗时的，因此，有可能网络的原因造成信件发送很慢，这是用户就一直等不到他的计算结果，很显然，我们使用监控式事件模式来解决，让发信的事件由监控者去完成，只要需要时触发就可以了： public class Computer extends Observable{ public Computer(){
//将sendMailObserver设定为本类的观察者。
addObserver(new sendMailObserver());
} .......
public void compute(String input,boolean needEmail,String email){
//计算操作
......... if (needEmail){ //设置变化点
setChanged();
//如果需要发送email，我们把email地址作为参数传送过去
notifyObservers(email); }
} ｝ |
我们再来看监控观察者代码是如何写的？ public class sendMailObserver implements Observer{ public void update(Observable obj,Object email){ if (email instanceof String){ sendMail(email); } } }
|
这样服务器在执行compute方法时，就没有发送邮件的等待，一直接继续执行。 <
说明：本教程来源互联网或网友上传或出版商，仅为学习研究或媒体推广，wanshiok.com不保证资料的完整性。
1/2 1 2 下一页 尾页 |
