因为 java 技术的开放性，因为 JCP 所给予开发人员的诸多选择性，作为 java 的研发/爱好者，在进行项目开发的时候，必然会面对 java 世界中的诸多框架,struts,spring,hibernate/ibatis 或者 servlet,ejb 等等--诸多开源的或者 JCP 组织所制定的标准框架，面对如此至多的框架，开发者该做何选择呢?

        众所周知，在 java EE5 规范正式发布之前，很多开源 framework 都非常出名，为人们喜爱并广泛使用，如 Struts、Spring、Hibernate 等，这些开放源代码的作品曾经一定程度上成为 Java 企业级应用开发事实上的标准。然而 2006 年 5 月，随着 Java EE 5 规范的正式发布，随着众多厂商对 java EE5 规范的众多产品或者技术的支持的推出，开源与标准之间的竞争不可避免的......

        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

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