重新带J2EE项目-兼谈架构模式的影响

 

写了几个月的通讯中间件,再次带领一个J2EE项目,使用WebWork、Spring、Hibernate,感觉写J2EE项目就像在休假,要考虑的事情少之又少,无论是效率、异常处理、线程调度、架构模式,一切都不再那么重要,无需考虑那么多,只要语义清晰,沟通流畅就好了。
想起一周前跟Jerry聊天,说起因为Unixware下JDK1.3的notify语义的不稳定问题而一天内重新编写了三次通讯框架,最后采用了完全非框架的过程化写法,Jerry说应该先写出一个实现,然后在之上重构,就像爬山一样,不可能一下子攀登到顶峰,当时虽然心里感觉不是这样,但竟一时语塞,不知从何说起,再次回到J2EE开发,才恍然明白那天的感觉,框架开发和业务开发的不同就在于,很难重构,尤其是通讯框架,架构通常决定了它的几个重要指标。

架构模式不同于设计模式,设计模式的问题可以通过重构解决,而架构模式几乎只能重新做(当然也有例外),架构一旦确定,很多东西就无法再加入,所以为什么很多开源的J2EE框架在大版本升级后不得不抛弃向后兼容。这也是为什么国产通讯框架Cindy的作者想在其中加入FilterChain,而最终放弃的原因,因为这对基础库的改动实在太大。

而MINA的架构就足够灵活,它屏蔽了不同通讯方式和通讯底层事件机制的差异,就像在如同Cindy和Netty2这种基于NIO的reactor模式之上的框架,要想重构到BIO,就几乎要全部重写,不过Netty2要好一些,毕竟有Netty1作为铺垫,所以在NIO的reactor的路上走的不是很远(NIO的reactor实现真是的不咋个),而MINA则只需要在SocketIoProcessor中使用Helf Sync/Helf Async模式替换掉reactor之上的事件处理即可,当然,最好还要提供线程池以便进行overload shield,在向Apache LDAP团队提交了MINA的JDK1.3核心库时也曾想提起该问题,可惜后太忙,忘记了。不过我想以Trustin的聪明,一定会想到这个问题。

你可能感兴趣的:(设计模式,spring,框架,Webwork,Mina)