其实，就算用java建造一个不是很烦琐的web应用，也不是件轻松的事情。 在构架的一开始就有很多事情要考虑。 从高处看，摆在开发者面前有很多问题：要考虑是怎样建立用户接口？在哪里处理业务逻辑？ 怎样持久化的数据。

而这三层构架中，每一层都有他们要仔细考虑的。 各个层该使用什么技术？ 怎样的设计能松散耦合还能灵活改变？ 怎样替换某个层而不影响整体构架？应用程序如何做各种级别的业务处理（比如事务处理）？

    构架一个web应用需要弄明白好多问题。 幸运的是，已经有不少开发者已经遇到过这类问题，并且建立了处理这类问题的框架。 一个好框架具备以下几点： 减轻开发者处理复杂的问题的负担（“不重复发明轮子”）； 内部有良好的扩展； 并且有一个支持它的强大的用户团体。 好的构架一般有针对性的处理某一类问题，并且能将它做好（do one thing well）。 然而，你的程序中有几个层可能需要使用特定的框架，已经完成的ui(用户接口) 并不代表你也可以把你的业务逻辑和持久逻辑偶合到你的ui部分。 举个例子， 你不该在一个controller(控制器)里面写jdbc代码作为你的业务逻辑， 这不是控制器应该提供的。 一个ui 控制器应该委派给其它给在ui范围之外的轻量级组件。 好的框架应该能指导代码如何分布。 更重要的是，框架能把开发者从编码中解放出来，使他们能专心于应用程序的逻辑（这对客户来说很重要）。

    这篇文章将讨论怎样结合几种着名的框架来使得你的应用程序做到松弛耦合。

    如何建立你的架构，并且怎样让你的各个应用层保持一致。？如何整合框架以便让每个层在以一种松散偶合的方式彼此作用而不用管低层的技术细节？这对我们来说真是一种挑战。 这里讨论一个整合框架的策略( 使用3 种受欢迎的开源框架) ：表示层我们用struts； 业务层我们用spring；而持久层则用hibernate。 你也可以用其他framework替换只要能得到同样的效果。 见图1 （框架组合示意图）

应用程序的分层

    大部分的web应用在职责上至少能被分成4层。 这四层是：presentation（描述），persistence（持久），business（业务）和domain model（域模块）。每个层在处理程序上都应该有一项明确的责任, 而不应该在功能上与其它层混合，并且每个层要与其它层分开的，但要给他们之间放一个通信接口。 我们就从介绍各个层开始，讨论一下这些层应该提供什么，不应该提供什么。

表示层(the presentation layer)

    一般来讲，一个典型的web应用的的末端应该是表示层。 很多java发者也理解struts所提供的。 象业务逻辑之类的被打包到org.apache.struts.action.， 因此，我们很赞成使用struts这样的框架。

下面是struts所负责的：

* 管理用户的请求,做出相应的响应。

* 提供一个controller ,委派调用业务逻辑和其它上层处理。

* 处理异常，抛给struts action

* 为显示提供一个模型

* ui验证。

以下条款，不该在struts显示层的编码中经常出现。 它们与显示层无关的。

* 直接的与数据库通信，例如jdbc调用。

* 与你应用程序相关联的业务逻辑以及校验。

* 事物管理。

在表示层引入这些代码，则会带来高偶合和麻烦的维护。

持久层(the persistence layer)

    典型的web应用的另一个末端是持久层。这里通常是程序最容易失控的地方。开发者总是低估构建他们自己的持久框架的挑战性。系统内部的持续层不但需要大量调试时间，而且还经常缺少功能使之变得难以控制，这是持久层的通病。 还好有几个orm开源框架很好的解决了这类问题。尤其是hibernate。 hibernate为java提供了or持久化机制和查询服务, 它还给已经熟悉sql和jdbc api 的java开发者一个学习桥梁，他们学习起来很方便。 hibernate的持久对象是基于pojo和java collections。此外，使用hibernate并不妨碍你正在使用的ide。

请看下面的条目，你在持久层编码中需要了解的。

* 查询对象的相关信息的语句。 hibernate通过一个oo查询语言（hql）或者正则表达的api来完成查询。 hql非常类似于sql-- 只是把sql里的table和columns用object和它的fields代替。 你需要学习一些新的hql语言； 不管怎样，他们容易理解而文档也做的很好。 hql是一种对象查询的自然语言，花很小的代价就能学习它。

* 如何存储，更新，删除数据库记录。

* 象hibernate这类的高级orm框架支持大部分主流数据库，并且他们支持 parent/child关系，事物处理，继承和多态。
业务层（the business layer） 

   一个典型web应用的中间部分是业务层或者服务层。 从编码的视角来看，这层是最容易被忽视的一层。 而我们却往往在ui层或持久层周围看到这些业务处理的代码，这其实是不正确的，因为它导致了程序代码的紧密偶合，这样一来，随着时间推移这些代码很难维护。幸好，针对这一问题有好几种frameworks存在。 最受欢迎的两个框架是spring和picocontainer。 这些为也被称为microcontainers，他们能让你很好的把对象搭配起来。 这两个框架都着手于‘依赖注射’(dependency injection)(还有我们知道的‘控制反转’inversion of control=ioc)这样的简单概念。 这篇文章将关注于spring的注射（译注：通过一个给定参数的setter方法来构造bean,有所不同于factory）, spring还提供了setter injection(type2)，constructor injection(type3)等方式供我们选择。 spring把程序中所涉及到包含业务逻辑和dao的objects――例如transaction management handler（事物管理控制）、object factoris(对象工厂)、service objects（服务组件）――都通过xml来配置联系起来。

后面我们会举个例子来揭示一下spring 是怎样运用这些概念。

业务层所负责的如下：

* 处理应用程序的 业务逻辑和业务校验

* 管理事物

* 允许与其它层相互作用的接口

* 管理业务层级别的对象的依赖。

* 在显示层和持久层之间增加了一个灵活的机制，使得他们不直接的联系在一起。

* 通过揭示 从显示层到业务层之间的context来得到business services。

* 管理程序的执行（从业务层到持久层）。

域模块层（the domain model layer ）
    既然我们致力于的是一个不是很复杂的web的应用， 我们需要一个对象集合，让它在不同层之间移动的。 域模块层由实际需求中的业务对象组成 比如, orderlineitem , product等等。 开发者在这层 不用管那些dtos，仅关注domain object即可。 例如，hibernate允许你将数据库中的信息存放入对象（domain objects），这样你可以在连接断开的情况下把这些数据显示到ui层。 而那些对象也可以返回给持续层，从而在数据库里更新。 而且，你不必把对象转化成dtos（这可能似的它在不同层之间的在传输过程中丢失），这个模型使得java开发者能很自然运用oo，而不需要附加的编码。

一个简单例子

既然我们已经从全局上理解这些组件。 现在就让我们开始实践吧。 我们还是用 struts，spring 和hibernate。这三个框架已经被描述够多了，这里就不重复介绍了。 这篇文章举例指导你如何使用这三个框架整合开发, 并向你揭示 一个请求是如何贯穿于各个层的。（从用户的加入一个order到数据库，显示；进而更新、删除）。

    既然每个层是互相作用的，我们就先来创建domain objects。首先，我们要在这些object中要确定那些是需要持久化的，哪些是提供给business logic，那些是显示接口的设计。 下一步，我们将配置我们的持久层并且定义好hibernate的or mappings。然后定义好business objects。有了这些组成部分之后，我们将 使用spring把这些连接起来。 最后，我们提供给spring一个持久层，从这个持久层里我们可以知道它是如何与业务逻辑层（business service layer）通信的，以及它是怎样处理其他层抛出的异常的。。

域对象层（domain object layer）

这层是编码的着手点，我们的编码就从这层开始。 例子中order 与orderitem 是一个one―to―many的关系。 下面就是domain object layer的两个对象：

? com.meagle.bo.order.java: 包含了一个order的概要信息

? com.meagle.bo.orderlineitem.java: 包含了order的详细信息

    好好考虑怎你的package命名,这反应出了你是怎样分层的。 例如 domain objects在程序中可能打包在com.meagle.bo内。 更详细一点将打包在com. meagle.bo的子目录下面。business logic应该从com.meagle.serice开始打包，而dao 对象应该位于com.meagle.service.dao.hibernate。反应forms和actions的 持久对象（presentation classes） 应该分别放在 com.meagle.action和com.meagle.forms包。 准确的给包命名使得你的classes很好分割并且易于维护，并且在你添加新的classes时，能使得程序结构上保持上下一致。

持久层的配置（persistence layer configuration）

    建立hibernate的持久层 需要好几个步骤。 第一步让我们把bo持久化。 既然hibernate是通过pojo工作的， 因此order和 orderlineitem对象需要给所有的fileds 加上getter,setter方法。 hibernate通过xml文件来映射(or)对象，以下两个xml文件分别映射了order 和orderitem对象。（这里有个叫xdoclet工具可以自动生成你的xml影射文件）

- order.hbm.xml
- orderlineitem.hbm.xml

    你可以在webcontent/web-inf/classes/com/meagle/bo目录下找到这些xml文件。hibernate的 [urlhttp://www.hibernate.org/hib_docs/api/net/sf/hibernate/sessionfactory.html]sessionfactory [/url]是用来告诉程序 应该与哪个数据库通信，该使用哪个连接池或使用了datasource， 应该加载哪些持久对象。而session接口是用来完成selecting，saving，delete和updating这些操作。 后面的我们将讲述sessionfactory和session是怎样设置的。

业务层的配置（business layer configuration）

    既然我们已经有了domain objects，接下来我们就要business service objects了，用他们来执行程序的logic,调用持久层，得到ui层的requests,处理transactions，并且控制exceptions。 为了将这些连接起来并且易于管理，我们将使用面向方面的 springframework。 spring 提供了 控制倒置（inversion of control 0==ioc)和注射依赖设置（setter dependency injection）这些方式（可供选择），用xml文件将对象连接起来。 ioc是一个简单概念（它允许一个对象在上层接受其他对象的创建），用ioc这种方式让你的对象从创建中释放了出来，降低了偶合度。

    这里是一个没有使用ioc的对象创建的例子，它有很高偶合度。

图 2.没有使用 ioc. a 创建了 b 和 c

    而这里是一个使用ioc的例子，这种方式允许对象在高层可以创建并进入另外一个对象，所以这样可以直接被执行。

图 3. 对象使用了 ioc。 a 包含了接受b,c的 setter方法 , 这同样达到了 由a创建b,c的目的。

建立我们的业务服务对象（building our business service objects）

    business object中的setter方法接受的是接口，这样我们可以很松散的定义对象实现，然后注入。 在我们的案例中，我们将用一个business service object接收一个dao,用它来控制domain objects的持久化。 由于在这个例子中使用了hibernate，我们可以很方便的用其他持久框架实现 同时通知spring 有新的dao可以使用了。

    在面向接口的编程中，你会明白 “注射依赖”模式是怎样松散耦合你的业务逻辑和持久机制的：）。

图 4. spring就是这样基于配置文件，将各个bean搭建在一起。

这个例子使用一个transactionproxyfactorybean，它定义了一个settransactionmanager()。 这对象很有用，他能很方便的处理你申明的事物还有service object。 你可以通过transactionattributes属性来定义怎样处理。 想知道更多还是参考transactionattributeeditor吧。

transactionproxyfactorybean 还有个setter. 这会被我们 business service object（ordertarget）引用， ordertarget定义了 业务服务层，并且它还有个属性，由setorderdao()引用。这个属性 

    spring 和bean 的还有一点要注意的： bean可以以用两种方式创造。 这些都在单例模式（sington）和原型模式（propotype）中定义了。 默认的方式是singleton,这意味着共享的实例将被束缚。 而原形模式是在spring用到bean的时候允许新建实例的。当每个用户需要得到他们自己bean的copy时，你应该仅使用prototype模式。（更多的请参考设计模式中的单例模式和原形模式）

提供一个服务定位器（providing a service locator）

    既然我们已经将我们的serices和dao搭配起来了。我们需要把我们的service显示到其他层。 这个通常是在struts或者swing这层里编码。一个简单方法就是用 服务定位器返回给spring context 。当然，可以通过直接调用spring中的bean来做。

下面是一个struts actin 中的服务定位器的一个例子。

代码:

public abstract class baseaction extends action {     private iorderservice orderservice;     public void setservlet(actionservlet                                  actionservlet) {     super.setservlet(actionservlet);     servletcontext servletcontext =                actionservlet.getservletcontext();       webapplicationcontext wac =       webapplicationcontextutils.          getrequiredwebapplicationcontext(                                  servletcontext);         this.orderservice = (iorderservice)                      wac.getbean("orderservice");   }     protected iorderservice getorderservice() {     return orderservice;   } }

ui 层配置 （ui layer configuration）

    这个例子里ui层 使用了struts framework. 这里我们要讲述一下在给程序分层的时候， 哪些是和struts部分的。我们就从一个struts-config.xml文件中的action的配置信息开始吧。

代码:

struts-config.xml file. <action path="/saveneworder"     type="com.meagle.action.saveorderaction"     name="orderform"     scope="request"     validate="true"     input="/neworder.jsp">   <display-name>save new order</display-name>   <exception key="error.order.save"     path="/neworder.jsp"     scope="request"     type="com.meagle.exception.orderexception"/>   <exception key="error.order.not.enough.money"     path="/neworder.jsp"     scope="request"     type="com.           meagle.           exception.           orderminimumamountexception"/>   <forward name="success" path="/vieworder.jsp"/>   <forward name="failure" path="/neworder.jsp"/> </action>

    saveneworder 这个action是用来持久化ui层里的表单提交过来order的。这是struts中一个很典型的action; 注意观察这个action中exception配置，这些exceptions也在spring 配置文件(applicationcontext-hibernate.xml)中配置了（就在 business service object 的transactionattributes属性里）。 当异常在业务层被被抛出时，我们可以控制他们，并适当的显示给ui层。

    第一个异常，orderexception,在持久层保存order对象失败的时候被触发。这将导致事物回滚并且通过bo把异常回传到struts这一层。

第二个异常，orderminimumamountexception也同第一个一样。

    搭配整和的最后一步 通过是让你显示层和业务层相结合。这个已经被服务定位器（service locator）实现了（前面讨论过了）， 这里服务层作为一个接口提供给我们的业务逻辑和持久层。

    saveneworder action 在struts中用一个服务定位器（service locator）来调用执行业务方法的。 方法代码如下：

代码:

public actionforward execute(   actionmapping mapping,   actionform form,   javax.servlet.http.httpservletrequest request,   javax.servlet.http.httpservletresponse response)   throws java.lang.exception {     orderform oform = (orderform) form;     // use the form to build an order object that   // can be saved in the persistence layer.   // see the full source code in the sample app.     // obtain the wired business service object   // from the service locator configuration   // in baseaction.   // delegate the save to the service layer and   // further upstream to save the order object.   getorderservice().saveneworder(order);     oform.setorder(order);     actionmessages messages = new actionmessages();   messages.add(       actionmessages.global_message,             new actionmessage(       "message.order.saved.successfully"));     savemessages(request, messages);     return mapping.findforward("success"); }

总结

    文章在技术和构架方面掩盖了很多低层的基础信息， 文章的主要的意图在于让你意识到如何给你应用程序分层。 分层可以“解耦”你的代码――允许新的组件被添加进来，而且让你的代码易于维护。 这里用到的技术只是专注于把“解偶”做好。 不管怎样，使用这样的构架可以让你用其他技术代替现在的层。 例如，你可能不使用hibernate实现持久化。既然你在dao中面向接口的编程的，所以你完全可以用ibatis来代替。或者，你也可能想用struts外的其他的技术或者框架替换现在的ui层（转换久层，实现层并不应该直接影响到你的业务逻辑和业务服务层）。 用适当的框架搭建你的web应用，其实也不是一件烦琐的工作，更主要的是它“解耦”了你程序中的各个层。

后记：

    这篇文章后，只是觉得很喜欢，于是就翻译了，当然同时也准备着挨大家扔来的鸡蛋：）。

    文章里并没有太多的技术细节，和详细的步骤。如果你从未使用过这些框架而在运行实例程序遇上困难的话，可以到csdn论坛java open source版发贴，我一定会详细解答的（啊哦，这不算做广告吧？），

    文章是从一个构架的角度讲述了如何搭配现有的开源框架进行分层， 有太多的术语我都不知道怎么表达，而且可能有很多语句存在错误。如果影响了你的阅读，请你直接点原文地址，我同时也象你说声抱歉。