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

http://blog.youkuaiyun.com/Jimbo_King/archive/2007/04/03/1550089.aspx

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的产品，提供更好的工具支持，这个答案才会明朗起来。