SCWCD之路——J2EE设计模式

最新推荐文章于 2024-09-26 16:41:53 发布

iteye_6883

最新推荐文章于 2024-09-26 16:41:53 发布

阅读量138

点赞数

分类专栏： SCWCD Certification 文章标签：设计模式网络应用应用服务器 JMS DAO

本文链接：https://blog.csdn.net/iteye_6883/article/details/81816535

版权

SCWCD Certification 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

概述

J2EE目前的设计模式有一类由Sun Java Center管理，其已经定义了15种设计模式，并且在《Core J2EE Patterns》中发表，有兴趣的可以去http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html 查看，考试中考到的设计模式就在其中。

这15种设计模式可以具体划分为：

1）Presentation Tier（表示层）

- Intercepting Filter

- Front Controller

- View Helper

- Component View

- Dispatcher View

- Service To Worker

2）Buiness Tier（业务逻辑处理层）

- Service Locator

- Business Delegate

- Session Facade

- Composite Entity

- Transfer Object

- Transfer Object Assemble

- Value List Handler

3）Integration Tier（集成层）

- Data Access Object

- Service Activator

设计模式让Web应用更加具有可维护性和灵活性，但是同时也增加了项目的复杂性，所以在使用各种模式的时候必须根据实际问题而选择合适的设计模式，而这也是考试中最容易考察的内容。

具体的设计模式分析

虽然SUN提供的设计模式有15种之多，但是考试的时候却不是全部会出现，这里只介绍经常会出现的几种模式。

1）Interception Filter

介绍：IF模式采用一个或多个过滤器来对客户的请求和服务器的响应做前处理和后处理，可以对一些操作做共同处理，如认证、页面导航、session管理等。

问题产生：表示层的处理机制会接收到许多不同的客户端的请求，有的请求只是简单地发送给目标组件，但是有些请求则必须做某些处理，如客户端是否被信任？客户端的浏览器是否受支持？等。这些判断及处理的代码应该写在什么地方呢？最简单的方法当然是用一系列的条件判断语句（if-else）来处理，但是这种简单的解决方法将导致代码十分脆弱，因为一旦条件发生改变，不得不修改原有代码，还容易产生copy-and-paste风格的代码。

解决方法：用一个标准的方式，来创建插件式（pluggable）的过滤器来做某些共同处理，使用这种方式无法改变核心的请求处理代码。这些过滤器通过对请求和响应进行拦截，做一些前/后处理，这样就能简单地通过增加/移除这些过滤器而无需对原有代码做任何修改。它的模式结构图如下：

优点：使用IF的好处有：1）不同的功能由不同的Filter类实现，它们被松耦合地组织在一起，由FilterManager和FilterChain集中控制。2）提高代码的可重用性。3）可以通过配置属性文件来增删过滤器，使得应用具有高度的可扩展性。

2）Front Controller

介绍：FC模式要求在Web应用的前端设置一个入口控制器，所有的客户请求都被发送到该控制器进行统一处理。一般可以用来做一些具有共同性的处理，如认证、session管理等。

问题产生：在开发Web应用的时候，如果让客户直接访问各个视图（如JSP页面），这样逻辑将被分散到各个视图里，可能会导致：1）对已有的功能修改困难，可维护性低。比如一旦session管理中的session发生改变，那么所有的视图的相关代码都需要修改。2）一旦需求改变，难以增加新的内容，缺乏可扩展性。比如现在想增加一个安全控制的功能，就必须在所有的视图中都加入处理代码，相同的逻辑将被重复分散到各个视图中，如下图：

解决方法：一个Web应用中经常会出现一些共同性的问题，如安全控制、允许访问IP、session管理等，使用IF模式可以强制分离视图中的显示逻辑和业务处理逻辑，将一些共同性处理的问题分离出来，如下图：

优点：使用FC的好处有：1）可以对Web应用进行集中控制。2）提高代码的可重用性和程序的可扩展性。3）提高了Web应用的可管理性。

3）Buiness Delegate

介绍：BD模式是在多层的Web应用中，在表示层和业务逻辑处理层之间增加一个代理层，通过这个代理层来隐藏业务逻辑处理层中的实现细节以及实现对业务逻辑的透明调用。

问题产生：在多层的Web应用系统中，有时需要进行远程方法调用和跨层的数据接收。这个时候如果直接让表示层的组件与业务逻辑处理层的组件直接交互，可能会导致：1）业务逻辑处理层的实现细节暴露给了表示层，一旦业务层的实现方法发生改变，那么表示层的代码也不得不跟着改变。比如当业务逻辑的实现由EJB2.0改成EJB3.0时。2）当表示层组件和业务逻辑处理层组件分别位于不同的网络环境时，直接访问或调用将引起过多的网络流量，影响系统的执行效率。

解决方法：使用BD模式来减少表示层和业务逻辑层直接的耦合性，通过BD模式来隐藏业务逻辑处理层的实现细节（比如lookup和对EJB的访问细节等）或者其他处理（如对数据进行缓存处理等），它的模式结构图如下：

优点：使用BD的好处有：1）减少了表示层和业务逻辑处理层之间的耦合性。2）加强了Web应用的集中控制管理能力，一旦应用的业务逻辑发生变化，则只需要修改代理层代码即可，不会影响到表示层代码。3）可以在代理层中做一些共同处理。4）隐藏了实现细节。5）代理层可以根据需要给表示层提供更好的接口。

4）Service Locator

介绍：SL模式是通过使用定位器来查找服务接口。

问题产生：客户端有时需要使用服务器提供的服务组件（如EJB、JMS等）来获取需要的服务，为了访问这些组件，客户端需要定位（通常称为lookup操作）这些组件或者创建一个新的组件。比如一个EJB的客户端必须定位enterprise bean的本地对象，客户将使用这个本地对象来创建或删除一个或更多的enterprise bean。同样一个JMS客户需要首先定位JMS的连接工厂来获取一个JMS Connection或JMS Session。所有的客户都使用JNDI公共设施来定位和创建EJB和JMS组件。这个时候，问题来了：1）许多类型的用户反复地使用JNDI服务，而JNDI的代码也多次被重复地出现在客户端，这样导致了许多不必要的重复代码。2）建立一个JNDI初始化Context对象需要大量的资源，如果多个用户对同一个bean本地对象重复要求将导致系统性能下降。

解决方法：使用SL模式来提高客户端使用JNDI来定位服务，使得当一个原出的对象被大量访问时性能不会迅速下降。

5）Transfer Object

介绍：TO模式主要用来减少客户端与服务器端之间的远程调用的数量，但是同时它也因为要处理远程的同步和版本控制等而增加了应用程序的复杂性。

优点：使用TO模式的好处有：1）减少了客户端与服务器端的远程调用数量，降低了网络阻塞。2）改善了客户端的响应时间。

6）Data Access Object

介绍：DAO模式是提倡使用DAO来抽象与封装所有对数据源的访问。

问题产生：许多的Web应用都需要存取持久化数据，这些持久化数据可以有多种不同的实现机制，比如它们可以是关系性数据库、文件系统、XML文件等。这些持久化数据的访问并没有统一的规格，需要访问持久化数据的组件可能是Entity Bean、JSP或者其他的Java对象等。如果这些组件中存在着访问持久化数据的代码，将可能会导致：1）各种组件跟数据持久化机制严重耦合，当数据库持久化机制发生改变时（比如用关系性数据库来代替原来的XML），这些组件都将需要修改。2）各个组件中存在大量相同的代码。3）不能支持多种不同的数据持久化机制。

解决方法：使用DAO来抽象与封装所有对数据源的访问，DAO负责管理对数据源的连接和对数据的访问，它的模式结构图下：