流行Web框架对比分析

时间:2022-01-26 17:14:58

 下班前,给Jameson, Mike, Jarod一起做了一个关于Webwork+FreeMarker框架的简单培训。通过给他们讲这些不同的技术框架,也让我有了心思将一些流行的框架进行以下分析和对比。

我们开发爱逛网(http://www.i-guang.com)用的是Struts,个人始终对这个Struts有点“偏见”,从Struts开始出来的时候就没有太多兴趣,觉得它虽然也比较好的实现了MVC,可总是显的不够优雅,每个Input页面都得一个FormBean,再需要一个基本相同代码的ModelObject,而且这种View--Action的模式也相对来讲不是很适合大规模的开发。

虽然Webwork与Struts基本上可以归为同一类的Web Framework,但是与Struts相比,Webwork要显的优雅很多。通过引入Interceptor的AOP机制,使的模块之间的耦合程度大大降低,而且View到ModelObject的映射实现方式OGNL(Object Graph Notation Language)也相对比较自然。另外,在Action的执行前后,也可以实现比Struts的Action更多的控制。当然,action chain更是Struts中没有的。

Velocity、FreeMarker这些并不能算是一个完整的Web框架,只能算是一个Web框架中所使用到的工具。

相比以上这些,我个人更看好JavaServer Faces,抛开JSF是标准而非一个简单的open source framework,个人认为,JSF将是未来发展的主流,因为软件开发“工业化”不可避免的是未来发展的方向。

JSF的主张是用Delphi的组件思想来开发Web应用程序。这个说起来容易,做起来很难。Web应用程序因为是基于Http等无状态协议的,不像C/S程序一样是实时连接(大部分是这样),服务器端很难维护客户端的状态。这也就是为什么Web应用可以比C/S程序拥有更多的并发访问用户的原因。

要实现这个“类C/S”开发,首先就需要对Web开发的琐碎细节进行抽象封装,将Web协议,各种细节技术隐藏,以一个可公用的组件去展现,这个确实是一个不小的工程。

JSF与Webwork/Struts等另一个很大的不同是:JSF没有用View-action机制,而是用了View-Backing Bean的机制,看上去一样,可原理却大不相同。Webwork/Struts中的action都是用了一种设计模式,比如command模式,让这些Action继承一个抽象类来实现某个特定的方法,用来处理页面输入。而JSF的Backing Bean确是充分利用了Java Bean的优点:简单,反射,灵活,IOC,没有用任何特别的设计模式,不需要继承或实现什么抽象类或接口,只需要一个简单的Bean(需要配置为Managed Bean,让容器来管理),而对页面中Form的submit action也可灵活的指定为Backing Bean中的任意一个方法。

此外,JSF还充分利用了Swing编程中的Event机制,通过EventListener实现无页面跳转的事件响应,而这个在Struts中实现起来是相对困难的。

从宏观层面上看,JSF具有其他框架所不具备的意义,那就是JSF更关注开发人员的分工,通过封装降低对开发人员的技能需求(比如页面开发人员对JavaScript技能的需求),实现了业务逻辑的组件封装重用....而这些,正是软件开发“流水线化”、“工业化”的必要条件。

虽然,开发自己的组件需要充分理解JSF的原理、底层细节,但是这只是一个小问题,而且一个框架的发展从来都是不断降低门坎的过程。

相信JSF会有一个灿烂的未来。

这次比较没有比较Spring,因为我觉得Spring与这些Web框架不是一类,基本不具备什么可比性。Spring更像一个可“海纳百川”的大框架,通过简单的IoC和AOP思想来实现不同模块之间的松散耦合,并且可以通过IoC来整合大部分Web Framework(关于IoC,请参见我的另外一片文章《理解IoC》。而且,Spring不单单可用于Web应用,其他应用同样可以使用Spring框架,可使用其AOP/Application Context/JDBC, ORM等部分。而,Spring与JSF很类似的一点就是:两者都充分使用了Java Bean技术。Spring中的BeanFactory,JSF中的Backing Bean。