一种优雅的流行架构：Struts+Spring+Hibernate

为何要用Struts+Spring+Hibernate

传统的java web应用程序是采用jsp+servlet+javabean来实现的,这种模式实现了最基本的MVC分层,使的程序结构分为几层,有负责显示的jsp、负责流程逻辑控制的servlet、负责数据封装的javabean.但是这种结构仍然存在问题:如jsp页面中需要使用符号嵌入很多的java代码,造成页面结构混乱,servlet和javabean负责了大量的跳转和运算工作,耦合紧密,程序复用度低等等.

于是先出现了struts框架,它是一个完美的MVC实现,它有一个中央控制类(一个Servlet),针对不同的业务,我们需要一个Action类负责页面跳转和后台逻辑运算,一个或几个jsp页面负责数据的输入和输出显示,还有一个Form类负责传递Action和jsp中间的数据.jsp中可以使用 struts框架提供的一组标签,就像使用html标签一样简单,但是可以完成非常复杂的逻辑.从此jsp页面中不需要出现一行包围的java代码了.

可是所有的运算逻辑都放在struts的Action里将使得Action类复用度低和逻辑混乱,所以通常人们会把整个web应用程序分为三层,struts负责显示层,它调用业务层完成运算逻辑,业务层再调用持久层完成数据库的读写.

使用jdbc连接来读写数据库,我们最常见的就是打开数据库连接、使用复杂的sql语句进行读写、关闭连接,获得的数据又需要转换或封装后往外传,这是一个非常烦琐的过程.

这时出现了hibernate框架,它需要你创建一系列的持久化类.每个类的属性都可以简单的看做和一张数据库表的属性一一对应,当然也可以实现关系数据库的各种表件关联的对应.然后我们****作时,只需要去****作这些持久化类,而不用再关注数据库表.我们不用再去一行行的查询数据库,只需要****作持久化类就可以完成增删改查的功能.使我们的软件开发真正面向对象,而不是面向混乱的代码.我的感受是,使用hibernate比jdbc方式减少了80％的编程量.

现在我们有三个层了,可是每层之间的调用是怎样的呢?比如显示层的struts需要调用一个业务类,就需要new一个业务类出来,然后使用;业务层需要调用持久层的类,也需要new一个持久层类出来用.通过这种new的方式互相调用就是软件开发中最糟糕设计的体现.简单的说,就是调用者依赖被调用者,它们之间形成了强耦合,如果我想在其他地方复用某个类,则这个类依赖的其他类也需要包含.程序就变得很混乱,每个类互相依赖互相调用,复用度极低.如果一个类做了修改,则依赖它的很多类都会受到牵连.

为此,出现spring框架,它的作用就是完全解耦类之间的依赖关系,一个类如果要依赖什么,那就是一个接口.至于如何实现这个接口,这都不重要了.只要拿到一个实现了这个接口的类,就可以轻松的通过xml配置文件把实现类注射到调用接口的那个类里.所有类之间的这种依赖关系就完全通过配置文件的方式替代了.所以spring框架最核心的就是所谓的依赖注射和控制反转.

现在的结构是,struts负责显示层,hibernate负责持久层,spring负责中间的业务层,这个结构是目前国内最流行的Java Web应用程序架构了.另外,由于Spring使用的依赖注射以及AOP（面向方面编程）,所以它的这种内部模式非常优秀,以至于Spring自己也实现了一个使用依赖注射的MVC框架,叫做Spring MVC,同时为了很好的处理事物,Spring集成了hibernate,使事物管理从Hibernate的持久层提升到了业务层,使用更加方便和强大.

struts框架是2000年就开始起步了,到目前已经发展了5年,技术相当成熟,目前全球Java开发中Struts框架是显示层技术中当之无愧的王者.它拥有大量的用户群和很好的开发团队.这也是国内大部分Java软件公司对新进员工的基本要求,所以我强烈推荐掌握struts技术,这对你们的就业会很有好处的.

Java这个名词似乎注定和开源紧密联系在一起了,在Java界,每天都有大量的开源技术出现,由于是开放源代码的,技术中存在的问题和不足很快就会被人发现,开源软件提供者会很快的修正或扩展这些技术,因此版本更新很快,几个星期或者几天就有一个新版本出来.

选择了Java,也就选择了你必须持续学习,你需要经常关注最新的技术,了解它们,看是否适合你的需要,然后学习使用它们.只要你一段时间不去关注和学习,那么你就落后于他人了,style="font-size:14px",只能做为coder,成不了主力,甚至被扫地出门.

-------------------------------------------------------------------------------------------------------------------------------------------------

 

用java来建立一个很有价值的web 应用不是一个简单的任务。在架构这个应用时要考虑很多的因素和问题。从更高的层次来看，开发人员面临着关于如何构建用户接口，何处驻留业务逻辑，以及如何实现数据持久性这些问题。这3层都有各自的问题需要回答。而每一层又需要实现那些技术？应用如何设计来进行松散耦合并能进行灵活变更？应用架构是否允许某一层变更而不影响到其它的层次？应用应该如何处理容器一级的服务比如事务？

在为你的应用创建一个架构之前有许多问题需要澄清。幸运的是，有很多开发者都意识到这个问题，并建立了很多框架来解决这些问题。一个良好的框架可以让开发人员减轻重新建立解决复杂问题方案的负担和精力；它可以被扩展以进行内部的定制化；并且有强大的用户社区来支持它。框架通常能很好的解决一个问题。然而，你的应用是分层的，可能每一个层都需要各自的框架。仅仅解决UI问题并不意味着你能够很好的将业务逻辑和持久性逻辑和UI 组件很好的耦合。例如，你不应该使具有JDBC代码的业务逻辑放入控制器之中，这不是控制器应该提供的功能。一个UI 控制器应该是轻量化的组件，由它代表对UI范围之外的其它应用层的服务调用。良好的框架自然地形成代码分离的原则。更为重要的是，框架减轻了开发人员从头构建持久层代码的精力，从而集中精力来应用逻辑上，这对客户端来说更为重要。

本文讨论了如何结合几个著名的框架来达到松散耦合，如何设计你的架构，以及如何达到各个层次的一致性设计。面临的挑战是，将框架整合起来，以使每一层都向另外的层次以一种松散的方式来暴露接口，而不管底层功能使用的是什么技术。本文还讨论整合3种著名开源框架的一种策略。对表现层，我们使用Struts；业务层使用Spring；对于持久层我们使用的是Hibernate。你尽可以取代这里的某个框架而使用你喜欢的框架已达到同样的效果。图1显示了框架被整合起来时，从最高层次看到的视图。

 

应用层

许多设计良好的web 应用，可以被按职责分为四层。这些层次是表现层、持久层、业务层、和领域模型层。每一个层次都有其独特的职责，不能把各自的功能与其它层次相混合。每一个应用层都应该和其它层隔离开来，但允许使用接口在层间进行通信。我们开始来看看每个层，并讨论一下它们各自都应该提供什么和不应该提供什么。

表现层

一个典型的web 应用的末端是表现层。许多Java 开发者都知道Struts 提供了什么东西。然而，太多时候，耦合代码比如业务逻辑被放进org.apache.struts.Action中。所以，我们先总结一下Struts 之类的框架应该提供什么。下面就是Struts 的职责所在：

• 管理用户的请求和响应
• 提供一个控制起来将调用委托到业务逻辑和其他上游处理
• 将来自于抛出例外的其他层的例外处理到Struts Action 中
• 组装可以在视图中表现的模型对象
• 执行UI 校验

下面是一些经常可以使用Struts进行编码但是不应该和表现层关联的事情：

• 直接和数据库交互，比如JDBC 调用
• 与应用相关的业务逻辑和校验
• 事务管理

在表现层中引入这些类型的代码将导致类型耦合和维护负担。

持久层

一个典型Web应用的另一端是持久层。这也是应用中最容易很快失控的地方。开发者通常低估了自己构建自己的持久层框架的挑战。一个定制的，内部开发的持久层不仅需要大量的开发时间，并且通常缺乏功能和难以管理。目前有许多解决这些问题的开源对象关系映射 (ORM) 框架。特别地， Hibernate 框架就允许Java中的对象-关系的持久性和查询服务。Hibernate 对已经熟悉了SQL 和JDBC API 的Java开发者来或具有中度的学习曲线。Hibernate 的持久对象基于POJO和Java 群集（collections）。此外，使用Hibernate 不和你的IDE接口。下面列出了你需要在持久性框架中编写的代码类型：

• 查询关系信息到对象中。Hibernate 是通过称为HQL的OO查询语言，或者使用更有表现能力的规则API，来完成这个工作的。除了使用对象而不是表，使用字段而不是列的方式，HQL非常类似于 SQL。也有一些新的特定的HQL 语言特征需要学习；但是，它们是很容易理解和良好编写的。HQL 是一种用于查询对象的自然语言，而对象，只需要很少的学习曲线吧。.
• 存储、更新和删除存储在数据库中的信息
• 高级的对象关系映射框架比如Hibernate支持大部分主流SQL数据库，它们支持父/子关系，事务，继承和多态。

下面是应该在持久层避免的一些事情：

• 业务逻辑应该置于应用的更高层中。这里只允许数据访问方法。
• 不应该使持久逻辑和表现逻辑耦合。避免表现组件如JSP或者基于servlet的类中的逻辑直接和数据访问进行通信。通过将持久性逻辑隔离在其自己的层中，应用将具有更加灵活的修改性而不影响到其他层的代码。例如， Hibernate 可以使用其他持久框架和API代替，而不需要修改其它层中的代码。

业务层

典型的Web应用的中间组件一般是业务层和服务层。从编程的角度来说，service layer经常被忽略。这种类型的代码散布于UI表现层和持久层并不是不多见。这些都不是正确的地方因为它导致了紧密耦合的应用和难以维护的代码。幸运的是，大多数框架都解决了这个问题。这个空间内最流行的两个框架是Spring 和PicoContainer。它们都被视为是具有非常小的足迹（footprint）并且决定如何将你的对象整合在一起的微容器（microcontainer）。这些框架都建立在一种叫做依赖性注入（dependency injection） (也称控制反转（inversion of control：IOC）)的简单概念之上。我们将关注Spring中通过针对命名配置参数的bean属性的setter 注入的使用。Spring 也允许一种更加高级的构造器注入（constructor injection）形式作为setter injection 的可选替代。对象通过简单的XML 文件进行连接，该配置文件包含对各种对象的引用，比如事务管理处理器（transaction management handler）,对象工厂，包含业务逻辑的服务对象，以及数据访问对象(DAO)。

我们随后会用一些例子来澄清Spring中使用这些改变的方式。

业务层应该负责下面的问题：

• 处理应用的业务逻辑和业务校验
• 管理事务
• 允许与其他层进行交互的接口
• 管理业务级对象之间的依赖性
• 加入了表现和持久层之间的灵活性，以便它们不需要彼此进行直接通信
• 从表现层暴露上下文给业务层以获得业务服务
• 管理从业务层到表现层的实现

领域模型层

最后，因为我们要解决实际的问题的web应用，我们需要一套在不同的层间移动的对象。领域模型层包含的是表达实际业务对象的对象，比如Order, OrderLineItem, Product 等等。这一层允许能让开发者不再构建和维护不必要的数据传输对象DTO来匹配其领域对象。例如， Hibernate允许你读取数据库信息到一个领域对象的对象图中，以便你可以在离线的情况下将其表现在UI层中。这些对象可以被更新并跨过表现层发送回去，然后进行数据库更新。另外，你不再需要将对象转变成DTO，因为它们在不同的层间移动时可能会丢失事务。这种模型允许Java 开发者能够以OO风格的方式很自然的处理对象，而不用编写额外的代码。

整合一个简单的例子

到此，应该对各种层次和组件有一个高层的理解了罢。可以开始一些实践了。再次说明。我们的例子整合了Struts, Spring, 和Hibernate 框架。每个框架都包含大量的内容细节，我们不会多述。我们的目的使用一个例子向你说明如何将它们整合在一起构建一个优雅的Web应用架构。实例将演示一个请求是如何得到各层的服务的。此应用的用户可以将一个订单保存在数据库中并且察看数据中的已有订单。进一步的增强允许将用户更新和删除现有订单。

首先，我们将常见我们的领域对象，因为它们是要和各层沟通的。这些对象将允许我们能够定义那些对象需要持久化，那些业务逻辑需要提供，以及应该设计那些表现接口。接下来，我们将使用Hibernate 来为领域对象配置持久层和定义对象关系映射。然后，我们将定义和配置我们的业务层。在完成这些组件后，我们将讨论如何使用Spring将这些层关联起来。最后，我们将提供一个表现层，它知道如何与业务服务层通信以及如何处理来自于其他层的例外。