他们的 简称 叫做 SSH SSH 整合理念 1.1 框架 用java 来建立一个很有价值的web 应用不是一个简单的任务。在架构这个应用时要考虑很多的因素和问题。从更高的层次来看，开发人员面临着关于如何构建用户接口，何处驻留业务逻辑，以及如何实现数据持久性这些问题。这3 层都有各自的问题需要回答。而每一层又需要实现那些技术？应用如何设计来进行松散耦合并能进行灵活变更？应用架构是否允许某一层变更而不影响到其它的层次？应用应该如何处理容器一级的服务比如事务？ 在为你的应用创建一个架构之前有许多问题需要澄清。幸运的是，有很多开发者都意识到这个问题，并建立了很多框架来解决这些问题。一个良好的框架可以让开发人员减轻重新建立解决复杂问题方案的负担和精力；它可以被扩展以进行内部的定制化；并且有强大的用户社区来支持它。框架通常能很 好的解决一个问题。然而，你的应用是分层的，可能每一个层都需要各自的框架。仅仅解决UI 问题并不意味着你能够很好的将业务逻辑和持久性逻辑和UI 组件很好的耦合。例如，你不应该使具有JDBC 代码的业务逻辑放入控制器之中，这不是控制器应该提供的功能。一个UI 控制器应该是轻量化的组件，由它代表对UI 范围之外的其它应用层的服务调用。良好的框架自然地形成代码分离的原则。更为重要的是，框架减轻了开发人员从头构建持久层代码的精力，从而集中精力来应用逻辑上，这对客户端来说更为重要。 本文讨论了如何结合几个著名的框架来达到松散耦合，如何设计你的架构，以及如何达到各个层次的一致性设计。面临的挑战是，将框架整合起来，以使每一层都向另外的层次以一种松散的方式来暴露接口，而不管底层功能使用的是什么技术。本文还讨论整合3 种著名开源框架的一种策略。对表现层，我们使用Struts；业务层使用Spring；对于持久层我们使用的是Hibernate。你尽可以取代这里的某个框架而使用你喜欢的框架已达到同样的效果。 1.2 应用层 许多设计良好的web 应用，可以被按职责分为四层。这些层次是表现层、持久层、业务层、和领域模型层。每一个层次都有其独特的职责，不能把各自的功能与其它层次相混合。每一个应用层都应该和其它层隔离开来，但允许使用接口在层间进行通信。我们开始来看看每个层，并讨论一下它们各自都应该提供什么和不应该提供什么。 1.2.1 表现层 一个典型的web 应用的末端是表现层。许多Java 开发者都知道Struts 提供了什么东西。然而，太多时候，耦合代码比如业务逻辑被放进org.apache.struts.Action 中。所以，我们先总结一下Struts 之类的框架应该提供什么。下面就是Struts 的职责所在： 管理用户的请求和响应 提供一个控制起来将调用委托到业务逻辑和其他上游处理 将来自于抛出例外的其他层的例外处理到Struts Action 中 组装可以在视图中表现的模型对象 执行UI 校验 下面是一些经常可以使用Struts 进行编码但是不应该和表现层关联的事情： 直接和数据库交互，比如JDBC 调用 与应用相关的业务逻辑和校验 事务管理 在表现层中引入这些类型的代码将导致类型耦合和维护负担。 1.2.2 持久层 一个典型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 代替，而不需要修改其它层中的代码。 1.2.3 业务层 典型的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)。 业务层应该负责下面的问题： 处理应用的业务逻辑和业务校验 管理事务 允许与其他层进行交互的接口 管理业务级对象之间的依赖性 加入了表现和持久层之间的灵活性，以便它们不需要彼此进行直接通信 从表现层暴露上下文给业务层以获得业务服务 管理从业务层到表现层的实现 1.2.4 领域模型层 最后，因为我们要解决实际的问题的web 应用，我们需要一套在不同的层间移动的对象。领域模型层包含的是表达实际业务对象的对象，比如Order, OrderLineItem, Product 等等。这一层允许能让开发者不再构建和维护不必要的数据传输对象DTO 来匹配其领域对象。例如， Hibernate 允许你读取数据库信息到一个领域对象的对象图中，以便你可以在离线的情况下将其表现在UI 层中。这些对象可以被更新并跨过表现层发送回去，然后进行数据库更新。另外，你不再需要将对象转变成DTO，因为它们在不同的层间移动时可能会丢失事务。这种模型允许Java 开发者能够以OO 风格的方式很自然的处理对象，而不用编写额外的代码。
一句话说不完！ 简单的介绍一下吧！struts是处理视图层和处理层的框架！ spring是管理javabeen的框架hibernate是处理持久层的框架 他用的是o/m思想，核心是对象关系映射。sping的核心是控制反转消除依赖！ 提高软件的可扩展性！Struts（表示层）+Spring（业务层）+Hibernate（持久层） Struts： Struts是一个表示层框架，主要作用是界面展示，接收请求，分发请求。 在MVC框架中，Struts属于VC层次，负责界面表现，负责MVC关系的分发。（View：沿用JSP，HTTP，Form，Tag，Resourse ；Controller：ActionServlet，struts-config.xml，Action） Hibernate： Hibernate是一个持久层框架，它只负责与关系数据库的操作。 Spring： Spring是一个业务层框架，是一个整合的框架，能够很好地黏合表示层与持久层。 我们知道，传统的Java Web应用程序是采用JSP+Servlet+Javabean来实现的(这是老的方式，现在用struct+sping+hibernate)，这种模式实现了最基本的MVC分层，使的程序结构分为几层，有负责前台展示的 JSP、负责流程逻辑控制的Servlet以及负责数据封装的Javabean。但是这种结构仍然存在问题：如JSP页面中需要使用符号嵌入很多的 Java代码，造成页面结构混乱，Servlet和Javabean负责了大量的跳转和运算工作，耦合紧密，程序复用度低等等。 Struts 为了解决这些问题，出现了Struts框架，它是一个完美的MVC实现，它有一个中央控制类(一个 Servlet)，针对不同的业务，我们需要一个Action类负责页面跳转和后台逻辑运算，一个或几个JSP页面负责数据的输入和输出显示，还有一个 Form类负责传递Action和JSP中间的数据。JSP中可以使用Struts框架提供的一组标签，就像使用HTML标签一样简单，但是可以完成非常复杂的逻辑。从此JSP页面中不需要出现一行包围的Java代码了。 可是所有的运算逻辑都放在Struts的Action里将使得 Action类复用度低和逻辑混乱，所以通常人们会把整个Web应用程序分为三层，Struts负责显示层，它调用业务层完成运算逻辑，业务层再调用持久层完成数据库的读写。 使用JDBC连接来读写数据库，我们最常见的就是打开数据库连接、使用复杂的SQL语句进行读写、关闭连接，获得的数据又需要转换或封装后往外传，这是一个非常烦琐的过程。 Hibernate 这时出现了 Hibernate框架，它需要你创建一系列的持久化类，每个类的属性都可以简单的看做和一张数据库表的属性一一对应，当然也可以实现关系数据库的各种表件关联的对应。当我们需要相关操作是，不用再关注数据库表。我们不用再去一行行的查询数据库，只需要持久化类就可以完成增删改查的功能。使我们的软件开发真正面向对象，而不是面向混乱的代码。我的感受是，使用Hibernate比JDBC方式减少了80%的编程量。 现在我们有三个层了，可是每层之间的调用是怎样的呢?比如显示层的Struts需要调用一个业务类，就需要new一个业务类出来，然后使用;业务层需要调用持久层的类，也需要new一个持久层类出来用。通过这种new的方式互相调用就是软件开发中最糟糕设计的体现。简单的说，就是调用者依赖被调用者，它们之间形成了强耦合，如果我想在其他地方复用某个类，则这个类依赖的其他类也需要包含。程序就变得很混乱，每个类互相依赖互相调用，复用度极低。如果一个类做了修改，则依赖它的很多类都会受到牵连。 为此，出现Spring框架。 Spring Spring的作用就是完全解耦类之间的依赖关系，一个类如果要依赖什么，那就是一个接口。至于如何实现这个接口，这都不重要了。只要拿到一个实现了这个接口的类，就可以轻松的通过xml配置文件把实现类注射到调用接口的那个类里。所有类之间的这种依赖关系就完全通过配置文件的方式替代了。所以 Spring框架最核心的就是所谓的依赖注射和控制反转。 现在的结构是，Struts负责显示层，Hibernate负责持久层，Spring负责中间的业务层，这个结构是目前国内最流行的Java Web应用程序架构了。另外，由于Spring使用的依赖注射以及AOP(面向方面编程)，所以它的这种内部模式非常优秀，以至于Spring自己也实现了一个使用依赖注射的MVC框架，叫做Spring MVC，同时为了很好的处理事物，Spring集成了Hibernate，使事物管理从Hibernate的持久层提升到了业务层，使用更加方便和强大。 Struts框架是2000年就开始起步了，到目前已经发展了5年，技术相当成熟，目前全球Java开发中Struts框架是显示层技术中当之无愧的王者。它拥有大量的用户群和很好的开发团队。这也是国内大部分Java软件公司对新进员工的基本要求。 其他 Java这个名词似乎注定和开源紧密联系在一起了，在Java界，每天都有大量的开源技术出现，由于是开放源代码的，技术中存在的问题和不足很快就会被人发现，开源软件提供者会很快的修正或扩展这些技术，因此版本更新很快，几个星期或者几天就有一个新版本出来。 当我们在技术线路中选择了Java，也就选择了你必须持续学习，经常关注最新的技术，了解它们，看是否适合你的需要，然后学习使用它们。
扫一扫
2197
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
