J2EE设计模式.ppt

1、J2EE设计模式,介绍 表示层模式 业务层模式 集成层模式,模式定义,每个模式都是由三部分组成的一个规则，这个规则描述特定环境、特定系统作用，以及特定软件配置之间的关系。其中特定系统作用力可以在特定环境中反复出现，并且特定软件配置可以使特定系统有能力解决自身存在的问题。 Richard Gabriel 每个模式都是由三部分组成的一个规则，这个规则描述特定环境、问题和解决方案之间的关系。 Christopher Alexander,模式模板,环境(Context)：设置该模式所存在的环境。 问题(Problem)：描述开发者所面临的设计事宜。 作用力(Forces)：列出影响问题和解决方案的原因

2、和 动机。 解决方案(Solution)：简单地描述解决方案方法，详细地描述解决方案元素。 结构：使用UML类图以显示该解决方案的基本结构。 策略：描述模式可能实现的各种不同方式。 结果(Consequences)：讨论模式的影响，给出该模式的优缺点。 相关模式(Related Patterns)：给出来自J2EE模式目录或其他外部资源的其他相关模式。,J2EE的层次模型,J2EE模式目录逻辑结构层,表示层 包括J2EE的表示层，由Web层的组件组成。 业务层 包括J2EE的业务服务，由EJB层和EIS层的组件组成。 集成层,J2EE模式目录表示层模式,截取过滤器 Intercepting F

3、ilter 前端控制器 Front Controller 视图助手 View Helper 复合视图 Composite View 工作者服务 Service to Worker 分发者视图 Dispatcher View,J2EE模式目录业务层模式,业务代表 Business Delegate 值对象 Value Object 会话外观 Session Facade 复合实体 Composite Entity 值对象组装器 Value Object Assembler 值列表处理器 Value List Handler 服务定位器 Service Locator,J2EE模式目录集成层模式,

4、数据访问对象 Data Access Object 服务激发器 Service Activator,模式关系,没有一个模式是独立的实体，每个模式都存在相互支持。 理解模式关系有助于： 当考虑应用某模式以解决自己的问题时可能出现的其他新问题。 使你能够重新审查模式关系以决定替代方法。 两个图表： J2EE模式关系图：从高层视角来表达模式和相互关系。 J2EE模式构架图：从低层视角来表达模式的相互关系，表达的是模式角色之间的相互关系。,J2EE模式关系图,J2EE模式构架图,介绍 表示层模式 业务层模式 集成层模式,截取过滤器,环境：表示层请求处理机制可以接收许多不同类型的请求，这些请求分别需要不

5、同类型的处理。 问题：一般需要预处理和后处理客户端Web请求和答复。 作用力：需要集中化常见逻辑；服务应该能正确地添加或者删除，而无须影响已有的组件。 相关模式：装饰模式（Decorator），是为动态可插拔包装器提供的。,截取过滤器,解决方案 创建可插拔的过滤器以标准的方式处理常见的服务，而无须更改核心的请求处理代码。 结构,截取过滤器模式类图,截取过滤器,策略 public final class DebuggingFilter implements Filter public void doFilter(ServletRequest req, ServletResponse res, F

6、ilterChain chain) throws IOException, ServletException /Complete filter processing here /Pass control to the next filter in the chain or to the target resource chain.doFilter(request, response); ,通过修改Web应用的部署描述符可以被公开地添加或删除 Debugging Filter ControllerServlet ,截取过滤器,结果 用松散耦合的处理器来集中化控制 提高可重用性 公开的和灵活的配置

7、 信息共享效率低下,前端控制器,环境： 表示层请求处理机制必须能够控制和协调每个用户跨越多请求的处理，这类控制机制可能以集中式或者分散的方式进行处理。 问题： 系统需要表示层请求处理的集中式访问点以支持系统服务的集成、内容检索、视图管理以及导航。即视图与控制器的交互。 作用力： 每个请求都要完成常见的系统服务处理 最适合在一个地方处理的逻辑却在多个视图中重复放置。 决策点存在依赖于数据的检索和操作。 可以使用多个视图以答复类似的业务请求。 在一个集中点处理请求很有用处。 系统服务和视图管理逻辑相对比较复杂。,前端控制器,解决方案 使用某控制器作为处理请求的最初联系点。控制器管理的请求处理包括：

8、 调用安全服务，比如验证和授权 委托业务处理 管理合适的视图选择 处理错误 管理内容创建逻辑的选择 分发者组件负责视图管理和导航 注意：应用程序会在系统中使用多个控制器，其中每个控制器映射到一组截然不同的服务。,前端控制器,前端控制器,结构,前端控制器,参与者和职责,前端控制器,策略 Servlet前端策略 JSP前端策略 命令和控制器策略 物理资源映射策略 逻辑资源映射策略 多元资源映射策略 控制者中分发者策略 基前端策略 过滤器控制器策略,前端控制器,结果 集中化控制 提高安全的可管理性 提高可重用性 用户跟踪、日志 确认和出错处理 相关模式 视图助手 截取过滤器 分发者视图和工作者服务,

9、视图助手,环境： 系统创建表示内容，而其中表示内容需要动态业务数据的处理。 问题： 业务数据访问和表示格式化逻辑混杂时，使系统灵活性更差，更缺乏可重用性。 混合业务和系统逻辑与视图处理会降低模块性，造成Web创作和软件开发组之间角色的不良分隔。 作用力： 业务数据消化需求是很重要的。 在视图中嵌入业务逻辑会增强拷贝粘贴类型的重用，产生维护问题。 希望明晰和区分工作分工，使不同人分别承担不同的软件开发者和Web创作组成员的角色。 通常使用一个视图以答复特定业务请求。,视图助手,解决方案 视图把其处理职责委托给其助手类，助手实现为JavaBean或者自定义标签，助手也存储该视图的中间数据，充当业务

10、数据适配器。 在助手中封装业务逻辑，增强应用程序的模块化。 应用该模式的前兆是scriptlet代码开始控制JSP视图时。 目标 从视图中分离出业务逻辑 划分应用程序的职责,视图助手,结构,视图助手,参与者和职责,视图助手,策略 JSP视图策略（推荐） Servlet视图策略 JavaBean助手策略 有助于内容检索 为了视图使用而调整和存储模型 易于管理，常用于命令对象 自定义标签助手策略 业务代表作为助手策略 助手组件对业务层做分布式调用，使用业务代表隐藏请求的低层实现策略，助手只需要调用业务服务。 转换器助手策略,视图助手,结果 增强应用程序划分、重用性和可维护性 增强角色独立 相关模式

11、 业务代表 分者者发视图和工作者服务 前端控制器,复合视图,环境： 复杂的Web页面可以展示来自多个数据源的内容，使用多个包含单显示页面的子视图。 问题： 不是把某视图的模块化的原子部分合并到一个复合体的机制，是通过直接在每个视图中嵌入格式化代码来形成这些页面。 多个视图的布局变化很难，容易出错，原因是存在重复的代码。 作用力： 视图内容的原子部分经常变化。 多个复合视图使用相似的子视图。 当子视图被直接嵌入和重复放置在多个视图中时，布局变化更难管理，代码更难维护。 直接在视图中嵌入经常变化的模板文本也会潜在地影响系统的有效性和可管理性。,复合视图,解决方案 使用由多个原子子视图组成的复合视图

12、，模板中的每个组件是动态合成在一起的，页面的布局可能是独立于内容进行管理的。 在提供了复合视图的创建方法，是基于模块化动态和静态模板片断的包含和替换操作完成的。,复合视图,结构,复合视图,参与者和职责,复合视图,策略 JSP视图策略（推荐） Servlet视图策略 JavaBean视图管理策略 标准标签视图管理策略 自定义标签视图管理策略 转换器视图管理策略 早期绑定资源策略 后期绑定资源策略,复合视图,结果 提高模块性和可重用性 增强灵活性 增强可维护性和可管理性 降低可管理性 性能影响 产生包含大量子视图的显示可能会降低性能 相关模式 视图助手 复合模式,工作者服务,环境： 系统控制着执行

13、流和对业务数据的访问，其中借助于业务数据，系统可以创建表示内容。 问题： 不存在管理访问控制、内容检索或者视图管理的集中化组件，并且在多个视图中存在重复的控制代码。 业务逻辑和表示格式化逻辑在这些视图中被混合，降低模块性，使系统灵活性更差。 作用力： 对每个请求都需要进行验证和授权检测。 视图中的scriptlet代码应该被最少化。 业务逻辑应该被封装在除视图之外的组件中。 控制流相对比较复杂，并且基于来自动态内容的值。 视图管理逻辑是相对比较高级的，因为其中多个视图潜在地映射到相同的请求。,工作者服务,解决方案 把控制器和分发者与视图和助手合并起来以处理客户端请求，准备动态表示作为答复。 分

14、发者负责视图管理和导航，可以被封装在控制器中，或者单独的组件中。 与分发者视图模式的区别： 对组件的工作划分不同 工作者服务： 控制器和分发者有更多的职责 分发者会在视图管理方面扮演一个重要的角色 分发者视图： 把内容检索推迟到视图处理的时候 分发者在视图管理方面扮演一个更有限的角色，视图选择通常已经包含在请求中,工作者服务,结构,工作者服务,参与者和职责,工作者服务,策略 Servlet前端策略（推荐） JSP前端策略 JSP视图策略（推荐） Servlet视图策略 JavaBean助手策略（推荐） 自定义标签视图策略 控制器中分发者策略 转换器助手策略,工作者服务,结果 集中化控制 提高模

15、块化和可重用性 提高应用程序划分 增强角色分离 相关模式 前端控制器 视图助手 分发者视图,分发者视图,环境： 系统控制执行流，以及对表示层处理的访问，其中表示层处理负责产生动态内容。 问题： 不存在管理访问控制、内容检索或者视图管理的集中化组件，并且在多个视图中存在重复的控制代码。 业务逻辑和表示格式化逻辑在这些视图中被混合，降低模块性，使系统灵活性更差。 作用力： 对每个请求都需要进行验证和授权检测。 视图中的scriptlet代码应该被最少化。 业务逻辑应该被封装在除视图之外的组件中。 控制流相对比较简单，并且通常基于封装在请求中的值。 视图管理逻辑受限于复杂性。,分发者视图,解决方案

16、把控制器和分发者与视图和助手合并起来以处理客户端请求，准备动态表示作为答复。 分发者负责视图管理和导航，可以被封装在控制器中、视图，或者单独的组件中。,分发者视图,结构,分发者视图,参与者和职责,分发者视图,策略 Servlet前端策略（推荐） JSP前端策略 JSP视图策略（推荐） Servlet视图策略 JavaBean助手策略（推荐） 自定义标签视图策略 控制器中分发者策略 转换器助手策略,分发者视图,结果 集中化控制 提高模块化和可重用性 提高应用程序划分 增强角色分离 相关模式 前端控制器 视图助手 工作者服务,介绍 表示层模式 业务层模式 集成层模式,业务代表,环境： 多层、分布式

17、系统需要远程方法调用来在层之间发送和接收数据，处理分布式组件的复杂性直接暴露给了客户端。 问题： 表示层组件与业务服务直接交互，会把业务服务API的低层实现细节暴露给表示层，使表示层组件对业务服务实现的变化很敏感。 使用业务服务API的表示层组件会通过网络做太多的调用。 把服务API直接暴露给客户端会强迫客户端处理与EJB技术分布式属性有关的网络问题。 作用力： 表示层客户需要访问业务服务。 诸如设备、Web客户和瘦客户机等不同的客户需要访问业务服务。 随着业务需求的发展，业务服务API会变化。 希望降低表示层客户端和业务服务之间的耦合。 客户端需要为业务服务信息实现缓冲机制。 希望降低客户端

18、和业务服务之间的网络流量。,业务代表,解决方案 使用业务代表来降低表示层客户端和业务服务的耦合。业务代表隐藏了业务服务的实现细节，比如EJB组件的查找和访问细节。 结构,业务代表,参与者和职责,业务代表,策略 代表代理策略,业务代表,策略 代表适配器策略,业务代表,结果 降低耦合，提高可管理性 转换业务服务异常 向客户端隐藏与低层实现细节有关的知识 实现失效恢复和线程同步 向业务层提供更简单的、统一的接口 影响性能 向表示层服务请求提供缓冲机制，更好的性能 相关模式 服务定位器 代理 适配器,值对象,环境： 应用程序客户端需要与企业bean之间交换数据。 问题： 在EJB应用程序中，业务服务对

19、象（无论是实体Bean，还是会话Bean）的远程调用方法是使用网络层服务，不关心客户端与该Bean的直接交互，带来了一定的网络负载。 作用力： 所有对EJB的访问是通过该EJB的远程接口实现的。 应用程序中的读事务比更新事务要多得多。 客户端经常需要多个属性的值或者EJB的相关对象。 客户端对EJB发起的调用数目影响着网络性能。,值对象,解决方案 使用值对象来封装业务数据。相应的方法调用是设置和检索值对象。当客户端向EJB请求业务数据时，该EJB可以构造值对象，用属性值来填充，传递给客户端。,结构,值对象,参与者和职责,值对象,策略 可更新的值对象策略,值对象,策略 多值对象策略,实体继承值对

20、象策略,值对象,策略 值对象工厂策略,值对象,结果 简化实体Bean和远程接口 在更少的远程调用中传递更多的数据 降低网络流量 降低代码重复性 可能引入旧值对象 由于同步和版本控制而也许会增加复杂性 并发访问和事务 相关模式 会话外观 值对象组装器 值列表处理器 复合实体,会话外观,环境： EJB封装了业务逻辑和业务数据，把它们的接口暴露给客户层，因而分布式服务的复杂性也暴露给客户层。 问题： 紧密耦合，会导致客户端和业务对象的直接依赖关系。 客户端和服务器之间的网络方法调用太多，容易导致网络性能问题。 缺乏统一的客户访问策略，容易误用业务对象。 作用力： 通过隐藏业务组件之间所有的复杂交互活

21、动，向客户端提供一个简单接口。 减少通过网络并跨越服务层被直接暴露给客户端的业务对象数目。 向客户端隐藏业务组件之间的低层交互和相互依赖关系。 提供统一的粗粒度服务层，以分离业务对象实现和业务对象抽象。 避免把低层业务对象直接暴露给客户端，使两个层之间的紧密耦合最小。,会话外观,解决方案 把会话bean用作外观以封装参与工作流的业务对象之间交互的复杂性。会话外观管理着业务对象，向客户端提供统一的粗粒度服务访问层。 会话外观： 抽象低层业务对象之间的交互活动，提供只暴露所需接口的服务层。 管理着业务数据和参与本工作流的业务服务对象之间的交互活动。 封装了与需求有关的业务逻辑。 根据工作流的需要进

22、行创建、定位查找、更改以及删除操作，管理着参与者的生命周期。 复杂应用程序中，把存活状态管理的任务委托给独立的对象。 业务对象之间的关系： 暂时的，模拟为工作流。 持久的，决定哪个业务对象负责维护持久关系。,会话外观,结构,会话外观,参与者和职责,会话外观,策略 会话外观策略 无状态会话外观策略 有状态会话外观策略 业务对象策略 会话bean策略 实体bean策略 数据访问对象策略,会话外观,结果 引入业务层控制器层 提供统一接口 减少耦合，提高可管理性 提高性能、减少细粒度方法 提供粗粒度访问 集中化安全管理 集中化事务控制 向客户端提供更少的远程接口 相关模式 外观 数据访问对象 服务定位

23、器 业务代表,复合实体,环境： 实体bean的目的不是代表对象模型中的每个持久性对象。实体bean更适合于粗粒度的持久性业务对象。 问题： 细粒度实体设计方法会影响许多领域： 实体关系 可管理性 网络性能 数据库模式依赖 对象粒度 作用力： 与每个实体bean相关的高负载，实体bean最好被设计为粗粒度对象。 直接把关系数据库模式映射到实体bean的应用程序会拥有大量的细粒度实体bean。 对象模型到EJB模型的直接映射会产生细粒度实体bean。 为了使用和支持实体bean，客户端不必了解数据库模式的实现。 过度的细粒度实体bean之间的通信会形成性能瓶颈。,复合实体,解决方案 使用复合实体来

24、模拟、表示和管理一组相互关联的持久性对象，而不是把它们表示成单个细粒度实体bean。复合实体bean表示一个对象树。 两种持久性对象 粗粒度对象 依赖对象 一个复合实体bean 表示为一个粗粒度对象及其相关的依赖对象 关系：树 根节点：粗粒度对象 叶节点：依赖对象,复合实体,结构,复合实体,参与者和职责,复合实体,策略 复合实体包含粗粒度对象策略 复合实体实现粗粒度对象策略 后期加载策略 存储优化(“脏”标记)策略 复合值对象策略,复合实体,结果 消除实体之间的关系 通过减少实体bean以提高可管理性 提高网络性能 减少数据库模式依赖性 提高对象粒度 加速复合值对象创建 相关模式 值对象 会话

25、外观 值对象组装器,值对象组装器,环境： 服务器端业务组件是使用会话bean、实体bean、DAO等等实现的。应用程序客户端会频繁地需要访问由多个对象组成的数据。 问题： 客户端单独访问模型中的每个分布式对象，有以下缺点： 客户端必须逐个访问每个分布式组件，存在紧密耦合关系。 客户端通过网络层访问分布式组件，降低性能。 从分布式组件获取模型的各部分数据后，客户端必须重新构造该模型。 模型的变化也需要对客户端做相应的变化。 作用力： 客户端和服务器端组件之间需要分隔业务逻辑。 希望最小化通过网络的远程调用的数目。 客户端执行某更新，只更新该模型的特定有关部分。 客户端不需要关注和了解模型实现中的

26、交互和依赖关系，松散耦合。,值对象组装器,解决方案 使用值对象组装器来创建所需要的模型和子模型。 值对象组装器使用值对象以从多个业务对象和定义该模型或者部分模型的其他对象检索数据。 值对象组装器构造一个复合值对象，该对象表示来自不同业务组件的数据。 不同的粒度 单个粗粒度对象把模型或者部分模型表现为单个值对象。 模型由多个粗粒度和细粒度组件共同组成，需要从不同组件获取值对象，把它们组装进一个新的复合值对象。,值对象组装器,结构,值对象组装器,参与者和职责,值对象组装器,策略 Java对象策略 会话Bean策略 无状态Bean 状态Bean 业务对象策略 业务对象被实现为会话Bean 业务对象是

27、实体Bean 业务对象是DAO 业务对象是任意Java对象 业务对象其他值对象组装器,值对象组装器,结果 分离业务逻辑 减少客户端和应用程序模型之间的耦合 提高网络性能 提高客户端性能 提高事务性能 引入过时值对象 相关模式 值对象 复合实体 会话外观 数据访问对象 访问定位器,值列表处理器,环境： 为了表示，客户端需要来自服务的项列表。列表中项的数目是未知的，并且在很多情况下其数量非常巨大。 问题： 大多数J2EE应用程序都有搜索和列出特定数据的搜索和查询需求。 使用可以产生大结果集的EJB查找方法会带来多种相关结果。 作用力： 客户端需要有效的查询机制来避免调用实体bean的ejbFind

28、()方法，以及调用每个返回的远程对象。 需要服务层缓冲机制以服务于那些不能接收和处理整个结果集的客户端。 在适度静态数据上反复执行的查询可以被优化以提供更快捷的结果。 EJB查找方法不适合于浏览整个数据库中完整的表，也不适合于搜索来自某表的大结果集。 EJB查找方法不适合于缓冲结果。 客户端希望在结果集中向前滚动或者先后查看。,值列表处理器,解决方案 使用值列表处理器来控制搜索、缓冲结果，以及以结果集的方式为客户端提供查询结果，其中结果集的大小和遍历满足客户端的需求。 创建ValueListHandler控制查询执行功能和结果缓冲。 ValueListHandler直接访问可以执行所需查询的D

29、AO. ValueListHandler以值对象集合的方式存储从DAO获取的结果。 客户端请求ValueListHandler根据需要提供查询结果。 ValueListHandler实现一个迭代器模式。,值列表处理器,结构,值列表处理器,参与者和职责,值列表处理器,策略 Java对象策略 有状态Bean策略,值列表处理器,结果 在大型查询方面，充当EJB查找方法的替代手段。 在服务器端缓冲查询结果 提供更好的查询灵活性 提供网络性能 允许延迟的实体bean事务 相关模式 迭代器 会话外观,服务定位器,环境： 服务查找和创建涉及复杂接口和网络操作。 问题： 客户端需要与诸如EJB和JMS组件进行

30、交互，为了交互客户端必须要么定位于该服务组件，要么创建一个新的组件。 多个客户端反复地请求相同的bean本地对象，会严重影响应用程序性能。 作用力： 通过使用EJB的注册JNDI名字，EJB客户端需要使用JNDI API来查找EJBHome对象。 通过使用为JMS组件注册的JNDI名字，JMS客户端需要使用JNDI API来查找JMS 组件。 组件的查找和创建可能比较复杂。 如果反复需要查找和创建，最初的环境创建和服务对象查找可能是很耗费资源的。 EJB客户端也许需要重新建立到以前被访问的EJB实例的连接，这些实例只拥有其Handle对象。,服务定位器,解决方案 使用服务定位器对象来抽取所有的

31、JNDI使用，隐藏最初环境创建、EJB本地对象查找和EJB对象重创建的复杂性。 多个客户端可以重新使用服务定位器对象来降低代码的复杂性，提供单点控制，通过提供缓冲机制来提高性能。 提供把所有依赖性和网络细节抽取到服务定位器的一种机制。 降低了客户端复杂性，该复杂性来自于客户端执行查找和创建的过程。,服务定位器,结构,服务定位器,参与者和职责,服务定位器,策略 EJB服务定位器策略 JMS队列服务定位器策略 JMS主题服务定位器策略 被合并的EJB和JMS服务定位器策略 类型检测服务定位器策略 服务定位器属性策略,服务定位器,结果 抽取复杂性 向客户端提供统一的服务访问 有利于添加新的业务组件

32、提高网络性能 通过缓冲而提高客户端性能 相关模式 业务代表 会话外观 值对象组装器,介绍 表示层模式 业务层模式 集成层模式,数据访问对象,环境： 根据数据源不同，数据访问也不同。根据存储的类型和供应商实现不同，持久性存储的访问差别也很大。 问题： 在RDBMS环境中，根据特定的数据库产品不同，SQL语句的语法和格式差别也许会很大。 持久性存储的类型差别很大。 组件中包含连接性和数据访问代码会引入组件与数据源之间的紧密耦合。 作用力： 组件需要从持久性存储和不同的其他数据源中检索数据，进行数据存储等操作。 根据产品供应商不同，持久性存储API差别也很大。 组件通常使用私有的API来访问外部的/遗产系统，来检索和存储数据。 组件中包含特殊的访问机制和API时，组件的可移植性受到影响