status+hibernate+Spring组装web应用框架的好处与不足.docx

status+hibernate+Spring组装web应用框架的好处与不足.docx

《status+hibernate+Spring组装web应用框架的好处与不足.docx》由会员分享，可在线阅读，更多相关《status+hibernate+Spring组装web应用框架的好处与不足.docx（15页珍藏版）》请在冰豆网上搜索。

status+hibernate+Spring组装web应用框架的好处与不足

status+hibernate+Spring框架有什么好处,有哪些不足？

一般的应用里struts负责的是前端表现层，处理页面提交跳转等处理，由其调用spring的接口处理业务。

spring层相当于业务处理层，负责业务逻辑的具体处理、事务控制，由其调用hibernate接口处理数据存取。

hibernate自然就是持久层。

这种结构与CS年代的三层结构也非常象，可以降低各个层次之间的耦合度，利于团队同步开发及模块复用。

不利当然是工作量及复杂度有所增加，运行效率稍有降低。

楼主说的status+hibernate模式少了业务处理层，如果在action或持久层做这事都不是很好，当然也可以另外写javabean，但相应的就会少了spring带来了这些好处了。

struts+spring+hibernate

三层结构分层明显，程序结构易懂，可扩展性强。

在一些小的项目里可能spring做的service层就只是直接return回dao层的调用而已，不过为了以后的扩展还是加上比较好。

我觉得三层结构也不会复杂到哪里去，相反程序看起来很清晰

struts不什么可说就是表示层那些标签

而hibernate是对数据库封装的通过ORM

而spring在其中启着成上启下的作用,首先他使个个层之间的解耦性降低,我想这是每个程序都想做到的,而且spring可以针对接口编程.更重要的是可以自动创建对象的了,不在用new了.

=========================================================================

1.struts

struts框架具有组件的模块化，灵活性和重用性的优点，同时简化了基于MVC的web应用程序的开发。

优点：

Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。

使开发者能更深入的了解其内部实现机制。

除此之外，Struts的优点主要集中体现在两个方面：

Taglib和页面导航。

Taglib是Struts的标记库，灵活动用，能大大提高开发效率。

另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。

关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。

通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。

尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。

另外，struts是业界"标准"（很多成功案例），学习资源丰富，HTML标签非常优秀

缺点：

Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。

Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。

ActionForms使用不便、无法进行单元测试（StrutsTestCase只能用于集成）

2．Hibernate

Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。

Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。

大多数开发机构经常采取创建各自独立的数据持久层。

一旦底层的数据结构发生改变，那么修改应用的其余部分使之适应这种改变的代价将是十分巨大的。

Hibernate适时的填补了这一空白，它为Java应用提供了一个易用的、高效率的对象关系映射框架。

hibernate是个轻量级的持久性框架，功能却非常丰富。

优点：

a.  Hibernate使用Java反射机制而不是字节码增强程序来实现透明性。

b   Hibernate的性能非常好，因为它是个轻量级框架。

映射的灵活性很出色。

c.  它支持各种关系数据库，从一对一到多对多的各种复杂关系。

缺点：

它限制您所使用的对象模型。

（例如，一个持久性类不能映射到多个表）其独有的界面和可怜的市场份额也让人不安，尽管如此，Hibernate还是以其强大的发展动力减轻了这些风险。

其他的开源持久性框架也有一些，不过都没有Hibernate这样有市场冲击力。

3．Spring

它是一个开源的项目，而且目前非常活跃；它基于IoC（InversionofControl，反向控制）和AOP的构架多层j2ee系统的框架，但它不强迫你必须在每一层中必须使用Spring，因为它模块化的很好，允许你根据自己的需要选择使用它的某一个模块；它实现了很优雅的MVC，对不同的数据访问技术提供了统一的接口，采用IoC使得可以很容易的实现bean的装配，提供了简洁的AOP并据此实现TranscationManagment，等等

优点  

a.Spring能有效地组织你的中间层对象，不管你是否选择使用了EJB。

如果你仅仅使用了Struts或其他为J2EE的API特制的framework，Spring致力于解决剩下的问题。

b.Spring能消除在许多工程中常见的对Singleton的过多使用。

根据我的经验，这是一个很大的问题，它降低了系统的可测试性和面向对象的程度。

c.通过一种在不同应用程序和项目间一致的方法来处理配置文件，Spring能消除各种各样自定义格式的属性文件的需要。

曾经对某个类要寻找的是哪个魔法般的属性项或系统属性感到不解，为此不得不去读Javadoc甚至源编码？

有了Spring，你仅仅需要看看类的JavaBean属性。

InversionofControl的使用（在下面讨论）帮助完成了这种简化。

d.  通过把对接口编程而不是对类编程的代价几乎减少到没有，Spring能够促进养成好的编程习惯。

e.Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。

在Spring应用中的大多数业务对象没有依赖于Spring。

f.使用Spring构建的应用程序易于单元测试。

g.Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。

你能选择用POJOs或localEJBs来实现业务接口，却不会影响调用代码。

h.Spring帮助你解决许多问题而无需使用EJB。

Spring能提供一种EJB的替换物，它们适用于许多web应用。

例如，Spring能使用AOP提供声明性事务管理而不通过EJB容器，如果你仅仅需要与单个数据库打交道，甚至不需要一个JTA实现。

i.  Spring为数据存取提供了一个一致的框架,不论是使用的是JDBC还是O/Rmapping产品（如Hibernate）。

Spring确实使你能通过最简单可行的解决办法来解决你的问题。

而这是有有很大价值的。

缺点：

使用人数不多、jsp中要写很多代码、控制器过于灵活，缺少一个公用控制器

J2EE是标准,Strutshibernatespring是实现了J2EE的某些标准的开源框架,比如Struts里的SERVLET,hibernate里的JDBC等等.

出处:

=======================================================

Struts+Spring+Hibernate组装web应用

其实，就算用Java建造一个不是很烦琐的web应用程序，也不是件轻松的事情。

当为一个应用程序建造一个构架时有许多事情需要考虑。

从高层来说，开发者需要考虑：

怎样建立用户接口？

在哪里处理业务逻辑？

和怎样持久化应用数据。

这三层每一层都有它们各自的问题需要回答。

各个层次应该使用什么技术？

怎样才能把应用程序设计得松耦合和能灵活改变？

构架允许层的替换不会影响到其它层吗？

应用程序怎样处理容器级的服务，比如事务处理？

当为你的web应用程序创建一个构架时，需要涉及到相当多的问题。

幸运的是，已经有不少开发者已经遇到过这类重复发生的问题，并且建立了处理这类问题的框架。

一个好框架具备以下几点：

减轻开发者处理复杂的问题的负担（“不重复发明轮子”）；内部定义为可扩展的；有一个强大的用户群支持。

框架通常能够很好的解决一方面的问题。

然而，你的应用程序有几个层可能都需要它们各自的框架。

就如解决你的用户接口（UI）问题时你就不应该把事务逻辑和持久化逻辑掺杂进来。

例如，你不应该在控制器里面写jdbc代码，使它包含有业务逻辑，这不是控制器应该提供的功能。

它应该是轻量级的，代理来自用户接口（UI）外的调用请求给其它服务于这些请求的应用层。

好的框架自然的形成代码如何分布的指导。

更重要的是，框架减轻开发者从头开始写像持久层这样的代码的痛苦，使他们专注于对客户来说很重要的应用逻辑。

这篇文章将讨论怎样组合几个著名的框架去做到松耦合的目的，怎样建立你的构架，怎样让你的各个应用层保持一致。

富于挑战的是：

组合这些框架使得每一层都以一种松耦合的方式彼此沟通，而与底层的技术无关。

这篇文章将使用3种流行的开源框架来讨论组合框架的策略。

表现层我们将使用Struts；业务层我们将使用Spring;持久层使用Hibrenate。

你也可以在你的应用程序中替换这些框架中的任何一种而得到同样的效果。

图1展示了当这些框架组合在一起时从高层看是什么样子。

图1：

用Struts，Spring，和Hibernate框架构建的概览

应用程序的分层

大多数不复杂的web应用都能被分成至少4个各负其责的层次。

这些层次是：

表现层、持久层、业务层、领域模型层。

每层在应用程序中都有明确的责任，不应该和其它层混淆功能。

每一应用层应该彼此独立但要给他们之间放一个通讯接口。

让我们从审视各个层开始，讨论这些层应该提供什么和不应该提供什么。

表现层

在一个典型的web应用的一端是表现层。

很多Java开发者也理解Struts所提供的。

然而，太常见的是，他们把像业务逻辑之类的耦合的代码放进了一个org.apache.struts.Action。

所以，让我们在像Struts这样一个框架应该提供什么上取得一致意见。

这儿是Struts负责的：

◆为用户管理请求和响应；

◆提供一个控制器代理调用业务逻辑和其它上层处理；

◆处理从其它层掷出给一个StrutsAction的异常；

◆为显示提供一个模型；

◆执行用户接口验证。

这儿是一些经常用Struts编写的但是却不应该和Struts表现层相伴的项目：

◆直接和数据库通讯，比如JDBC调用；

◆业务逻辑和与你的应用程序相关的验证；

◆事务管理；

◆在表现层中引入这种代码将导致典型耦合和讨厌的维护。

持久层

在典型web应用的另一端是持久层。

这通常是使事情迅速失控的地方。

开发者低估了构建他们自己的持久层框架的挑战性。

一般来说，机构内部自己写的持久层不仅需要大量的开发时间，而且还经常缺少功能和变得难以控制。

有几个开源的“对象－关系映射”框架非常解决问题。

尤其是，Hibernate框架为java提供了“对象－关系持久化”机制和查询服务。

Hibernate对那些已经熟悉了SQL和JDBCAPI的Java开发者有一个适中的学习曲线。

Hibernate持久对象是基于简单旧式Java对象和Java集合。

此外，使用Hibernate并不妨碍你正在使用的IDE。

下面的列表包含了你该写在一个持久层框架里的代码类型：

查询相关的信息成为对象。

Hibernate通过一种叫作HQL的面向对象的查询语言或者使用条件表达式API来做这个事情。

HQL非常类似于SQL--只是把SQL里的table和columns用Object和它的fields代替。

有一些新的专用的HQL语言成分要学；不过，它们容易理解而且文档做得好。

HQL是一种使用来查询对象的自然语言，花很小的代价就能学习它。

保存、更新、删除储存在数据库中的信息。

像Hibernate这样的高级“对象－关系”映射框架提供对大多数主流SQL数据库的支持，它们支持“父/子”关系、事务处理、继承和多态。

这儿是一些应该在持久层里被避免的项目：

业务逻辑应该在你的应用的一个高一些的层次里。

持久层里仅仅允许数据存取操作。

你不应该把持久层逻辑和你的表现层逻辑搅在一起。

避免像JSPs或基于servlet的类这些表现层组件里的逻辑和数据存取直接通讯。

通过把持久层逻辑隔离进它自己的层，应用程序变得易于修改而不会影响在其它层的代码。

例如：

Hebernate能够被其它持久层框架或者API代替而不会修改在其它任何层的代码。

#p#

业务层

在一个典型的web应用程序的中间的组件是业务层或服务层。

从编码的视角来看，这个服务层是最容易被忽视的一层。

不难在用户接口层或者持久层里找到散布在其中的这种类型的代码。

这不是正确的地方，因为这导致了应用程序的紧耦合，这样一来，随着时间推移代码将很难维护。

幸好，针对这一问题有好几种Frameworks存在。

在这个领域两个最流行的框架是Spring和PicoContainer，它们叫作微容器，你可以不费力不费神的把你的对象连在一起。

所有这些框架都工作在一个简单的叫作“依赖注入”（也通称“控制反转”）的概念上。

这篇文章将着眼于Spring的为指定的配置参数通过bean属性的setter注入的使用。

Spring也提供了一个构建器注入的复杂形式作为setter注入的一个替代。

对象们被一个简单的XML文件连在一起，这个XML文件含有到像事务管理器、对象工厂、包含业务逻辑的服务对象、和数据存取对象这些对象的引用。

这篇文章的后面将用例子来把Spring使用这些概念的方法说得更清楚一些。

业务层应该负责下面这些事情：

◆处理应用程序的业务逻辑和业务验证；

◆管理事务；

◆预留和其它层交互的接口；

◆管理业务层对象之间的依赖；

◆增加在表现层和持久层之间的灵活性，使它们互不直接通讯；

◆从表现层中提供一个上下文给业务层获得业务服务；

◆管理从业务逻辑到持久层的实现。

领域模型层

最后，因为我们讨论的是一个不是很复杂的、基于web的应用程序，我们需要一组能在不同的层之间移动的对象。

领域对象层由那些代表现实世界中的业务对象的对象们组成，比如：

一份订单、订单项、产品等等。

这个层让开发者停止建立和维护不必要的数据传输对象（或者叫作DTOs）,来匹配他们的领域对象。

例如，Hibernate允许你把数据库信息读进领域对象的一个对象图，这样你可以在连接断开的情况下把这些数据显示到UI层。

那些对象也能被更新和送回到持久层并在数据库里更新。

而且，你不必把对象转化成DTOs，因为DTOs在不同的应用层间移动，可能在转换中丢失。

这个模型使得Java开发者自然地以一种面向对象的风格和对象打交道，没有附加的编码。

结合一个简单的例子

既然我们已经从一个高的层次上理解了这些组件，现在就让我们开始实践吧。

在这个例子中，我们还是将合并Struts、Spring、Hibernate框架。

每一个这些框架在一篇文章中都有太多的细节覆盖到。

这篇文章将用一个简单的例子代码展示怎样把它们结合在一起，而不是进入每个框架的许多细节。

示例应用程序将示范一个请求怎样跨越每一层被服务的。

这个示例应用程序的一个用户能保存一个订单到数据库中和查看一个在数据库中存在的订单。

进一步的增强可以使用户更新或删除一个存在的订单。

因为领域对象将和每一层交互，我们将首先创建它们。

这些对象将使我们定义什么应该被持久化，什么业务逻辑应该被提供，和哪种表现接口应该被设计。

然后，我们将配置持久层和用Hibernate为我们的领域对象定义“对象-关系”映射。

然后，我们将定义和配置我们的业务对象。

在有了这些组件后，我们就能讨论用Spring把这些层连在一起。

最后，我们将提供一个表现层，它知道怎样和业务服务层交流和知道怎样处理从其它层产生的异常。

领域对象层

因为这些对象将和所有层交互，这也许是一个开始编码的好地方。

这个简单的领域模型将包括一个代表一份订单的对象和一个代表一个订单项的对象。

订单对象将和一组订单项对象有一对多的关系。

例子代码在领域层有两个简单的对象：

◆com.meagle.bo.Order.java:

包括一份订单的概要信息；

◆com.meagle.bo.OrderLineItem.java:

包括一份订单的详细信息；

考虑一下为你的对象选择包名，它将反映你的应用程序是怎样分层的。

例如：

简单应用的领域对象可以放进com.meagle.bo包。

更多专门的领域对象将放入在com.meagle.bo下面的子包里。

业务逻辑在com.meagle.service包里开始打包，DAO对象放进com.meagle.service.dao.hibernate包。

对于forms和actions的表现类分别放入com.meagle.action和com.meagle.forms包。

准确的包命名为你的类提供的功能提供一个清楚的区分，使当故障维护时更易于维护，和当给应用程序增加新的类或包时提供一致性。

持久层配置

用Hibernate设置持久层涉及到几个步骤。

第一步是进行配置持久化我们的领域业务对象。

因为我们用于领域对象持久化的Hibernate和POJOs一起工作，因此，订单和订单项对象包括的所有的字段的都需要提供getter和setter方法。

订单对象将包括像ID、用户名、合计、和订单项这样一些字段的标准的JavaBean格式的setter和getter方法。

订单项对象将同样的用JavaBean的格式为它的字段设置setter和getter方法。

Hibernate在XML文件里映射领域对象到关系数据库。

订单和订单项对象将有两个映射文件来表达这种映射。

有像XDoclet这样的工具来帮助这种映射。

Hibernate将映射领域对象到这些文件：

Order.hbm.xml

OrderLineItem.hbm.xml

你可以在WebContent/WEB-INF/classes/com/meagle/bo目录里找到这些生成的文件。

配置HibernateSessionFactory使它知道是在和哪个数据库通信，使用哪个数据源或连接池，加载哪些持久对象。

SessionFactory提供的Session对象是Java对象和像选取、保存、更新、删除对象这样一些持久化功能间的翻译接口。

我们将在后面的部分讨论Hibernate操作Session对象需要的SessionFactory配置。

#p#

业务层配置

既然我们已经有了领域对象，我们需要有业务服务对象来执行应用逻辑、执行向持久层的调用、获得从用户接口层的请求、处理事务、处理异常。

为了将所有这些连接起来并且易于管理，我们将使用Spring框架的bean管理方面。

Spring使用“控制反转”,或者“setter依赖注入”来把这些对象连好，这些对象在一个外部的XML文件中被引用。

“控制反转”是一个简单的概念，它允许对象接受其它的在一个高一些的层次被创建的对象。

使用这种方法，你的对象从必须创建其它对象中解放出来并降低对象耦合。

这儿是个不使用IoC的对象创建它的从属对象的例子，这导致紧的对象耦合：

图2：

没有使用IoC的对象组织。

对象Ａ创建对象Ｂ和Ｃ

这儿是一个使用IoC的例子，它允许对象在一个高一些层次被创建和传进另外的对象，所以另外的对象能直接使用现成的对象［译者注：

另外的对象不必再亲自创建这些要使用的对象］：

图3：

对象使用IoC组织。

对象Ａ包含setter方法，它们接受到对象Ｂ和Ｃ的接口。

这也可以用对象Ａ里的接受对象Ｂ和Ｃ的构建器完成

建立我们的业务服务对象

我们将在我们的业务对象中使用的setter方法接受的是接口，这些接口允许对象的松散定义的实现，这些对象将被设置或者注入。

在我们这个例子里我们将使我们的业务服务对象接受一个DAO去控制我们的领域对象的持久化。

当我们在这篇文章的例子中使用Hibernate，我们可以容易的转换到一个不同的持久框架的实现，通知Spring使用新的实现的DAO对象。

你能明白编程到接口和使用“依赖注入”模式是怎样宽松耦合你的业务逻辑和你的持久化机制的。

这儿是业务服务对象的接口，它是一个DAO对象依赖的桩。

publicinterfaceIOrderService{

　publicabstractOrdersaveNewOrder（Orderorder）

　　throwsOrderException,

　　　　　OrderMinimumAmountException;

　publicabstractListfindOrderByUser（Stringuser）

　　　　　　　　　　　　　throwsOrderException;

　publicabstractOrderfindOrderById（intid）

　　　　　　　　　　　　　throwsOrderException;

　publicabstractvoidsetOrderDAO（IOrderDAOorderDAO）;

}

注意上面的代码有一个为DAO对象准备的setter方法。

这儿没有一个getOrderDAO方法因为它不是必要的，因为不太有从外面访问连着的OrderDAO对象的需要。

DAO对象将被用来和我们的持久层沟通。

我们将用Spring把业务服务对象和DAO对象连在一起。

因为我们编码到接口，我们不会紧耦合实现。

下一步是写我们的DAO实现对象。

因为Spring有内建的对Hibernate的支持，这个例子DAO将继承HibernateDaoSupport类，这使得我们容易取得一个到HibernateTemplate类的引用，HibernateTemplate是一个帮助类，它能简化HibernateSession的编码和处理HibernateExceptions。

这儿是DAO的接口：

publicinterfaceIOrderDAO{

　publicabstractOrderfindOrderById（finalintid）;

　publicabstractListfindOrdersPlaceByUser（finalStringplacedBy）;

　publicabstractOrdersaveOrder（finalOrderorder）;

}

我们还有两个对象要和我们的业务层连在一起。

这包括HibernateSessionFactory和一个TransactionManager对象。

这在Spring配置文件里直接完成。

Spring提供一个HibernateTransactionManager，它将从工厂绑定一个HibernateSession到一个线程来支持事务。

这儿是HibernateSessionFactory和HibernateTransactionManager的Spring配置。

＜beanid="mySessionFactory"

　　　class="org.springframework.orm.hibernate.

　　　　　　　LocalSessionFa