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

<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280"></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的产品，提供更好的工具支持，这个答案才会明朗起来。

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

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

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）	支持	支持 < 分享到： 我们为什么需要Java EE 5.0？ | 使用事务与锁，实现一个用户取过的数据不被 ... 2008-04-10 18:29 浏览 693 评论(0) 查看更多 相关推荐 SSH整合jar包-spring5.0+hibernate5.1+struts2.5 SSH整合是指将Spring、Hibernate和Struts这三大Java开源框架集成在一起，用于构建高效、灵活的企业级Web应用程序。这三个框架分别负责不同的职责：Spring作为应用的基石，提供依赖注入（DI）和面向切面编程（AOP），... eclipse搭建（Struts2.5+Spring5.0+hibernate5.2）整合框架Demo实例 本教程将详细介绍如何使用Eclipse IDE搭建一个基于Struts2.5、Spring5.0和Hibernate5.2的整合框架，提供一个可运行的Demo实例。这个组合是Java企业级开发中常见的技术栈，它们各自负责不同的职责：Struts2作为前端... SSH框架简单快速搭建MyEcplise 2013(spring2.5+struts2.1+hibernate3.1) SSH框架是一种广泛应用于Java Web项目的开发框架，通过整合Spring、Struts和Hibernate三个强大的开源项目，可以显著提高开发效率，简化项目结构。 #### 开发工具与框架版本 - **开发工具**: MyEclipse 2013 - **... J2EE程序开发规范（中文）（支持标准：Java EE 5.0） 《J2EE程序开发规范（中文）》是针对Java EE 5.0版本的一套详细的开发准则，旨在规范轻量级J2EE应用程序的开发流程，提高代码质量和团队协作效率。以下将详细解读规范中的核心内容。 1. **开发环境与技术标准**： ... SSH框架配置步骤图解（Struts2.1.6 Spring2.5.6 Hibernate3.3.1 2 我们需要 MyEclipse5.5、JDK 1.6、Java EE 5.0、Tomcat6.0、Struts2.1.6、Spring2.5.6 和 Hibernate3.3.1。首先，下载 Struts2.1.6、Hibernate3.3 和 Spring2.5 的安装包。 接下来，打开 MyEclipse，新建一个 Web ... myeclipse6 整合struts spring hibernate 根据提供的文档内容，本文将详细解析如何在MyEclipse 8.5环境下整合Struts、Spring和Hibernate（简称SSH）框架。此过程分为几个步骤：准备实验环境、创建工程、添加Struts支持、添加Spring支持、整合Struts与Spring... Struts Hibernate Spring 基础篇 Struts、Hibernate、Spring 是Java开发中常用的三个框架，它们分别负责不同的职责：Struts作为MVC模式的实现，主要用于处理Web层的请求和响应；Hibernate是一个对象关系映射（ORM）框架，它简化了数据库操作；Spring... MYECLIPSE + STRUTS2 + SPRING4 + HIBERNATE4 + STRUCTS2S+OGNL + MYSQL_5.7.12 根据提供的标题、描述以及部分内容，本文将详细解析与MYECLIPSE + STRUTS2 + SPRING4 + HIBERNATE4 + STRUCTS2S+OGNL + MYSQL_5.7.12相关的技术栈及其应用。这些技术在企业级开发中非常常见，能够帮助开发者构建高效... struts+hibernate+spring框架配置 在这个配置教程中，我们将以MyEclipse5.5作为开发工具，使用JDK 1.6、Java EE 5.0、Tomcat6.0以及Struts2.1.6、Spring2.5.6和Hibernate3.3.1这些版本的组件来搭建SSH框架。 首先，确保你的开发环境已经准备就绪。你... 良葛格Gossip_struts_spring_hibernate 标题“良葛格Gossip_struts_spring_hibernate”表明这是一个关于编程框架和技术教程的集合，其中涵盖了Spring、Struts和Hibernate等关键组件。描述提到是Spring技术手册的作者提供的教程，暗示内容可能深入且权威。 ... STRUTS2+SPRING+HIBERNATE集成 【STRUTS2+SPRING+HIBERNATE集成】是一种经典的Java企业级应用开发框架组合，也被称为S2SH。这个集成方案主要用于构建高效、可维护性高的Web应用程序。以下将详细介绍这三个组件以及它们如何协同工作。 **Struts 2*... SSH整合之精华版 Struts2+Spring+Hibernate SSH整合是Java Web开发中常见的三大框架Struts2、Spring和Hibernate的集成，这个精华版教程旨在帮助初学者快速理解和掌握SSH的配置与应用。以下是关于SSH整合的一些关键知识点： **1. 开发环境** SSH整合通常需要... SSH框架配置Struts2.1.6+Spring2.5.6+Hibernate3.3.1 2 SSH框架，全称为Struts2、Spring和Hibernate的组合，是一种流行的企业级Java Web应用程序开发框架。这个框架的集成能够帮助开发者实现模型-视图-控制器（MVC）设计模式，提供数据持久化，以及应用层的管理和依赖注入... ssh(struts2.2.1+_hibernate3.6+spring3.0.5)整合配置 SSH（Struts2、Hibernate和Spring）是一种流行的Java企业级应用程序开发框架的组合，用于构建高效、可维护的Web应用。下面将详细介绍如何整合Struts2.2.1、Hibernate3.6和Spring3.0.5。 首先，确保准备好所有必要的... Struts 2,Spring 2,Hibernate S2SH 整合例子 Struts 2、Spring 2 和 Hibernate 是三个非常流行的开源框架，它们的整合通常被称为 S2SH（Struts 2 + Spring 2 + Hibernate）。这个整合使得开发人员能够利用Struts 2处理Web层的MVC（Model-View-Controller）架构... hibernate3.2+spring2.5+struts2.1配置过程.doc 在本文中，我们将详细探讨如何配置一个基于Java的Web应用程序，使用Hibernate3.2作为持久层框架，Spring2.5作为应用上下文管理和依赖注入工具，以及Struts2.1作为MVC框架。这个组合通常被称为SSH（Struts2、Spring、... Global site tag (gtag.js) - Google Analytics