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


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

放在自己的博客吧.
看一下论坛使用规则...

这篇VS文章写的不错，有一定参考价值
几乎每个较大规模的项目初期，架构师都要在技术选型上VS一番
so，不要过敏，不要教条，不要在心里设跟风式的文字狱

JSF没有前途，技术上已经过时了，而且一个强烈依赖IDE的web框架无论如何也不符合敏捷高效的要求，而且就是JSF引以为傲的组件技术也粒度太粗，可重用性很低，灵活性很差。

就web框架的技术水平和理念上面，不得不说，rails1.2目前最领先的。

EJB3.0的功能性比Spring2.0差很多，而且不够灵活，cluster不是一个障碍，SNA架构的Spring本身就是cluster-like的，EJB3会有一定的市场，但是各个方面的比较都不如spring2.0。

Hibernate和EJB3不冲突，事实上Hibernate3.2已经实现EJB3的JPA规范。

作为金蝶来说，写这种宣传文章替自己所谓的通过了Java EE5.0认证的应用服务器做宣传，不足为奇。

看好JSF
JSF是个与ASP.NET对应的东西，BEA、Oracle、IBM、SUN等公司都主推JSF，并在开发工具上做了强力支持。Web层不是软件的核心，最重要的是开发效率，没有太多讲究，IDE重不重无所谓，用起来方便就行，没有IDE支持的Web框架是没有前途的，没有IDE的界面开发是痛苦的，利用文本编辑器一行一行堆砌界面的事太傻。
JSF的灵魂是事件机制，很灵活，很自然，用户交互的本质就是一个个事件，传统的页面-响应式框架（Struts、Webwork）很难高效处理复杂的双向交互过程，手工编写AJAX的方式可以呈现给用户不错的交互体验，但是开发效率过低，不会成为主流，很多JSF组件已经包装了AJAX机制，可以兼顾开发效率和用户体验。
常用界面元素组件化，组件由专业公司和组织提供，应用开发人员没必要把时间浪费在这些基础元素的开发上，把做好的零件拿来用就是了。事件机制＋组件化是目前能看到最好的Web层开发方向。
优点：
  事件机制、组件化、IDE支持的可视化开发、生命力
目前发现的缺点：
　自定义组件比较麻烦，客户端很难控制组件，服务器端很难扩充组件，不过如果JSF组件库足够丰富和强大，自定义的需求会越来越少；
　JSF组件还不够丰富，IDE还不够方便，现在发现做的最好的是JDeveloper。

netbeans的可视化开发包对jsf支持的也非常好。组件直接拖放。

为了自己的利益、饭碗和立场，说出来的话自然就会不同以往了。

金蝶现在管理层易主，估计将来的宣传手法也会发生变化……

大公司主推不意味就有前途，也不意味着好用，EJB2.0就是一个很好的例子。

作为web层框架来说，IDE并不是重要的考量，ruby on rails是彻头彻尾的没有良好IDE支持，那为什么开发速度这么快呢？

作为这两年强调web标准的应用来说，IDE的帮助就更小了。真正提高开发效率的开发方式是每个人用<div>去写自己的页面片断，最后用CSS进行统一布局。

说到AJAX不得不说，JSF从原理上就是和AJAX冲突的，现在所谓的包装方式也很简陋。

最后你自己也说到的JSF组件复用能力比较差，组件比较少，这个差和少并不是因为组件不够丰富导致的，而是因为web开发对于界面要求的多样性导致的，所以JSF这种依赖IDE画界面，依赖大颗粒度的组件的框架并不适合现代web开发。

目前通过NetBeans的开发工具很好的支持了JSF开发组件，开发模式就和VisualStudio net开发一样，实现了直接拖拉式的开发，但目前我却感觉不到有什么优势！

我一看转自金碟 我就知道结论肯定是"能取代" 呵呵