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

【引自张勇的博客】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