Java EE 5.0能取代Struts，Spring和Hibernate吗？

<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog.html" frameborder="0" width="728" scrolling="no" height="90"></iframe>

2006年5月，Java EE 5规范正式发布。Java EE 5的出现，可能是J2EE诞生以来比较重量级的一次震撼，规范发布至今已有半年之多，业界对Java EE 5的关注也变得越来越热烈，google一下“java ee”关键字，可以得到500多万条相关纪录，而从Sun网站上进行检索（http://java.sun.com/javaee/overview/compatibility.jsp），也可以看到专业厂商已经迅速跟进，除Sun公司本身外，包括全球闻名的SAP、金蝶Apusic等另三家，已经推出全面支持Java EE 5规范的应用服务器产品。

Java EE 5包含JSF 1.2、EJB 3.0及JAX-WS 2.0等新功能，试图解决Java企业级应用开发的简便性、灵活性及易用性问题。在Java EE 5出现之前，很多开源框架（Open Source Framework）如雨后春笋般涌现，尝试从某种角度或某些方面去解决“委员会”规范所未能顾及的应用开发问题，如Web开发中的关注分离问题（MVC）、业务模型实现问题（ORM）等等。很多开源framework都非常出名，为人们喜爱并广泛使用，如Struts、Spring、Hibernate等，这些“江湖派”作品曾经一定程度上成为Java企业级应用开发事实上的标准。Java EE 5的出现，是否会改变这种状况？或者说，人们在重新选择应用框架时，是否会优先考虑全新的Java EE 5技术？带着这种疑问，笔者试图进行简单的技术比较，并辅于肤浅的评论，希望能够抛砖引玉、借花献佛，以娱大众。

Struts vs. JSF

	Struts	JSF
MVC	支持	支持
POJO		支持
页面流（Page Flow）	支持	支持
UI组件（UI Component）		支持

MVC是模型（Model）、视图（View）、控制（Controller）分层的结构，通过分层来实现关注分离，减少传统开发中常见并重复的工作。Struts和JSF均支持MVC。Struts对MVC支持的核心是Controller，通过Controller（一个共同的入口Servlet）获得HTTP请求，将HTTP参数传入ActionForm，然后将ActionForm传给Action类。Struts对HTTP请求只有一个事件处理handler，当请求过来时，由相应Action返回结果给前端Controller，并据此选择如何进行导航。JSF一般也采用一个前端Controller（有些商用JSF能够智能识别JSF请求，无需额外的controller），不过在Controller中做的工作跟Struts Controller截然不同，它负责触发JSF页面组件中的事件，用Render工具生成组件的展现，绑定来自Model的数据到组件等。可以看到，JSF在在控制层更灵活，在视图层支持Render工具的变换而生成灵活的展现，在模型层实现与框架的彻底分离，因而具有更高的灵活性。

POJO是无格式Java对象（Plain Old Java Object）。POJO与AOP结合被广泛用于快速业务模型。Struts设计的初衷主要是解决视图和控制问题，并无过多关注模型的灵活性问题。Struts中的ActionForm模型必须继承自框架类，虽然可以通过定制类库提供一些帮助类实现模型与框架无关，但本质上还是紧耦合于JSP- and HTTP-centric方法。JSF提供了对POJO天然的良好支持，并支持通过RAD工具实现快速的业务模型生成，从而具有更高的生产力。

页面导航的最大意义是帮助实现页面的可视化开发，在UI界面上快速定义页面流向。页面导航分静态导航和动态导航两种，静态导航是页面直接流向另一页面，动态导航是由特定动作或逻辑决定页面的流向。Struts和JSF均支持静态和动态页面导航。不过Struts中的导航规则是绑定到Action中的，那意味着可能需要对同一页面中不同的Action做重复性的导航规则制定，而JSF导航可以跟Action无关，可以在页面中不同组件的不同Action间共享相同的导航规则。

Struts本身并不提供UI组件机制，而JSF则提供了完整的UI组件机制。通过UI组件的定制和重用，能够极大地简化开发，提升用户体验。商业化的产品则往往更进一步，提供强大易用的开发工具，实现drag-and-drop方式所见即所得的Web UI开发。

Spring vs. EJB 3.0

	Spring	EJB3
标准（Standard）		是，Java EE 5标准组成部分
持久（Persistence）	JDBC, Hibernate, JDO, iBatis and JPA（ongoing spring 2.0）	JPA
声明式服务（Declarative Services）	支持	支持
依赖注入（Dependency Injection）	支持	支持
集群（Cluster）		支持

Spring框架是一个开源项目，并不是一个标准的东西。Spring自己定义了一套XML配置文件大纲以及程序接口，从长远考虑，有很大的不确定性。Spring的主要开发者来自Interface21公司（这是帮我非常敬重的人），Interface21靠相关咨询和服务维持，作为一个商业团体其利益取向将可以完全左右Spring未来的方向。相比EJB 3出身名门正派的标准血统并有众多主流商业厂商支持，Spring的非标准性将可能带来极大的风险。

Spring框架本身不带持久实现，但它支持JDBC, Hibernate, JDO和 iBatis等持久化框架。Spring通过使用不同的DAO和Helper类以利用JDBC、Hibernate、iBatis或JDO，所以并没有实现和最终服务提供者的隔离。简单来说，就是需要重构代码才能实现持久化框架的更换。EJB 3.0的持久集成在应用服务中，通过JPA，可以在底层更换持久实现，如将Hibernate更换为Toplink。EJB 3.0的持久具有更大的灵活性，并有利于厂商进行性能优化和扩展。

Spring和EJB3.0都为企业应用提供运行时服务，（如：事务、安全、日志消息、配置服务）。由于这些服务都不是直接与应用的业务逻辑相关联，所以都不是由应用来自行管理。EJB3.0使用Java注释来配置声明式服务，Spring使用XML配置文件。在大多数情况下，EJB3.0的注释声明显得更为简单和优雅。Spring使用XML来定义属性并配置声明式服务的结果将是一个冗长而不稳定的配置文件。

依赖注入模式（DI）是在应用中实现松散耦合的最佳实践。Spring和EJB3.0都支持DI模式，但他们有着深刻的不同。Spring支持通用的（但复杂的）基于XML配置文件的依赖注入API。EJB3.0支持注入大多数服务对象（如EJB和上下文对象）和通过简单注释声明的JNDI对象。

EJB 3.0完全支持集群。部署在服务集群中的EJB3.0应用将自动获得负载均衡、分布缓存、状态复制等功能。底层的集群服务隐藏在EJB3.0编程接口后面，屏蔽了所有的复杂性。Spring没有简单的利用集群的方法。

Hibernate vs. EJB 3.0

ibernate与EJB 3.0其实并没有很好的可比性，因Hibernate仅关注ORM，而 EJB 3.0更多则更多表现为一种组件框架，其中包含ORM部分而已。EJB 3.0在设计过程中，曾经得益于Hibernate的作者Gavin King，据说EJB 3.0 EntityBean的设计理念完全来自于Hibernate。只需用将EJB 3.0 EntityBean API调用转换为Hibernate API，Hibernate就可以成为EJB 3.0中EntityBean的 Implementation。

当开源framework已经成为习惯性势力，并给人们带来众多乐趣或疲惫感的时候，Java EE 5的出现会是适逢其时吗？无论如何，是继续选择开源还是拥抱Java EE 5？相信今天这并不是个容易的选择，或许，随着更多的厂商发布支持Java EE 5的产品，提供更好的工具支持，这个答案才会明朗起来。