6、 数据访问对象
数据访问对象(data access object，DAO)模式将数据访问逻辑抽象为特殊的资源，也就是说将系统资源的接口从其底层访问机制中隔离出来；通过将数据访问的调用打包，数据访问对象可以促进对于不同数据库类型和模式的数据访问。
这种模式出现的背景在于数据访问的逻辑极大程度上取决于数据存储的格式，比如说关系型数据库、面向对象数据库、磁盘文件等。
目前大部分的J2EE应用程序都需要在一定程度上使用可持久性的数据，而实现持久性数据的方法因应用程序不同而异，并且访问不同存储格式数据的应用程序接口(API)也有着显著的差别；有的时候，应用程序还会访问存储在不同操作平台上的数据，这使得问题更为复杂，通常，应用程序会使用共享的分布式组件，如实体bean来表达持久性数据。应用程序可以使用bean管理的持久性实体bean，而在实体bean中植人数据访问逻辑，或者使用容器管理的持久性实体bean，从而使容器管理所有的事务和持久性细节；而如果应用程序对于数据访问的需求十分简单的话，也可以采用会话bean或Servlet直接访问持久性存储来读取和修改数据。
一些应用程序可以使用JDBC应用程序接口来访问关系数据库中的数据，JDBC负责一般的持久性数据访问和管理，在J2EE应用程序中，JDBC中可以嵌入SQL语句，用以访问关系型数据库，当然根据数据库类型的不同，SQL语句的词法和语法也会有所不同；需要说明的是，当数据存储格式不同的时候，数据访问逻辑的区别就更加明显了，例如关系型数据库、面向对象数据库和磁盘文件，各自数据的访问逻辑各有千秋，这样一来就造成了程序代码和数据访问代码之间的依赖关系；当程序组件，即实体bean、会话bean或servlet、JSP等需要访问数据源时，它们会使用正确的应用程序接口来得到连接并管理数据源，但这样也会造成这些组件与数据源物理实现之间的依赖关系，从而使得应用程序很难从一个数据存储实体移植到另一个数据存储实体中去；当数据源的物理实现变化的时候，应用程序也必须相应地加以改变。
基于以上所讨论的问题，开发人员开始采用数据访问对象的方法。数据访问对象实际上就是包含对于所有数据访问逻辑的对象，并管理着对于数据源的连接，根据数据源的不同，数据访问对象实现了不同的访问机制，这里所说的数据源可以是持久性存储介质，如关系型数据库，也可以是外部服务，如B2B的数据交换；不仅是用户，而且包括应用系统中的其他组件，也可以使用数据访问对象所提供的数据访问接口，数据访问对象将数据源的物理实现细节与其用户完全分离开来，并且在底层数据源变化的时候，数据访问对象向用户提供的接口是不会变化的；这种方法使应用系统使用数据访问对象时可以适应多种数据存储介质，总之，数据访问对象就是系统组件和数据源中间的适配器。
图8中的类图表示了数据访问对象设计模式的参与对象和之间的调用关系，图9是这种设计模式的序列图。
图8 数据访问对象类图
图9 数据访问对象序列图
对于图9序列图中的组件加以解释如下：
(1)业务对象(Business Object)。表示数据的用户，它需要对于数据的访问，一个业务对象可以用会话bean、实体bean或是其他Java程序来实现。
(2)数据访问对象(Data Access Object)。数据访问对象是这种模式中的主题，它提供了底层数据访问的对象，并将其提供给业务对象以使得后者能够透明地访问数据源；同时业务对象也将数据的加载和存储操作移交给数据访问对象处理。
(3)数据源(Data source)。这里指的是数据源的物理实现，这个数据源可以是一个数据库，包括关系型数据库、面向对象数据库或文件系统。
(4)传输对象(Transfer Object)。这里的传输对象指的是数据载体。数据访问对象可以使用传输对象来向用户返回数据，而数据访问对象同样可以从用户那里得到传输对象来对数据源中的数据进行更新。
下面给出几种实现数据访问对象设计模式的方法。
(1)自动数据访问对象代码的生成
既然每一个业务对象都对应于一个数据访问对象，那么开发人员就可以建立业务对象、数据访问对象和底层实现的关系；一旦这种关系建立起来，开发人员就可以为所有的数据访问对象编写特殊的代码生成工具。
生成数据访问对象的信息通常存储在一个开发人员定义的描述文件中，如果对于数据访问对象的要求过于复杂，开发人员可以考虑使用第三方工具来为关系型数据库提供对象对关系的映射。这些工具通常是一些GUI程序，可以用来将业务对象映射为持久性的存储对象，并定义中间运作的数据访问对象，在映射完成的时候，这些工具可以自动地生成代码，并提供一些相应的功能，如缓存结果、缓存查询、与应用服务器整合、与第三方产品整合等。
(2)数据访问对象代理(Factory for Data Access Objects)
当底层的数据存储不会轻易改变的时候，开发人员可以采取这种方法来实现相应的，数据访问对象，图10是这种方法的类图。
图10 使用DAO代理类图
当底层的数据存储可能会变化的时候，开发人员可以采用抽象代理的方法来实现数据访问对象；抽象代理的方法会创建一些虚拟的数据访问对象代理和各种类型的实际数据访问对象代理，每种对象对应一种持久性存储介质的实现，一旦组件得到这些代理，就可以利用来创建需要使用的数据访问对象。
图11给出了这种情况的类图。该类图表示了一个基础的数据访问对象代理，它是一个抽象类，被其他一些实际的数据访问对象代理继承以支持特定的数据访问函数；用户可以得到一个实际的数据访问对象，并利用它来创建需要的数据访问对象而访问相关的数据，每一个实际的数据访问对象都负责建立对于数据源的连接，并得到和管理所支持的业务数据。
图11 抽象代理使用DAO
下图12是这种情况下的序列图。
图12抽象代理使用DAO序列图
这种设计模式的优势：
透明性好。业务对象可以在不知道数据源实现细节的情况下访问数据。由于一切数据访问细节被数据访问对象所隐藏，所以这种访问过程是透明的。
可移植性好。在应用系统中添加数据访问对象，可以使得前者能够很方便地移植到另外一种数据库实现上。业务对象与数据实现是隔离的，所以在移植过程中，仅仅对数据访问对象进行一些变化即可。
减少业务对象的代码复杂度。由于数据访问对象可以管理所有的数据访问复杂细节，这也就简化了业务模块和其他数据客户的代码。同时也提高了应用系统的整体可读性和开发率。
集中处理所有数据访问。由于所有的数据访问操作都移交给数据访问对象，这样应用系统其他部分就与数据访问实现隔离开来，而全部相关操作都与数据访问对象集中处理，这样也使得相关操作更加容易被维护和管理。
这种设计模式的缺陷：
对于容器管理的持久性不能利用。如果EJB容器采取容器管理的方式，那么所有对于持久性数据存储的管理都由容器负责。这样的话应用系统就无需实现数据访问对象了，因为应用服务将透明地提供这一功能。
添加了额外的层面。数据访问对象在数据用户和数据源之间添加了一个层面，也就增加了一些额外的设计和实现的负担。当然，我们认为它是物有所值的。
总之，在开发人员选择不同模式的时候，应该注意，一定的模式对应于一定的应用层次。比如说，与视图和显示相关的模式就是在Web层应用的。而一些与业务逻辑控制相关的模式则是与EJB层次相关的。另外一些关于读取数据和分派操作的模式则适用于不同的层次之间
7、值对象或传输对象
值对象(value object)模式通过减少分布式通信的消息而促进数据的交换，通常这里所指的通信是在Web层和EJB层之间。在一个远程调用中，一个单一值对象可以被用来取出一系列相关数据并提供给客户。
这种设计模式的出现是基于客户需要与ejb大量地交换数据的情况。具体来说，在J2EE平台中，应用系统通常将服务器端的程序组件实现为会话bean和实体bean，而这些组件的部分方法则需要将数据返回给客户；这种情况下，通常一个用户会重复调用相关方法多次，直到它得到相关信息，应该注意的是，多数情况这些方法调用的目的都是为了取得单一的信息，例如用户名或者用户地址等。
显而易见，在J2EE平台上，这种调用基本上都是来自远程的。也就是说，用户多次调用相应的方法会给Web带来极大的负担，即使用户和EJB容器加载相同的JVM、OS和计算机上运行EJB程序，由于方法调用被缺省地认为是远程任务，所以这种问题依然存在。
由于以上所提到的问题，在远程方法的调用次数增加的时候，相关的应用程序性能将会有很大的下降，因此利用多次方法调用而取得单一的信息是非常低效的；在这种情况，J2EE的研究人员建议使用传输对象来包含所有的程序数据，即每次方法调用可以发送和接收这个传输对象；当用户向EJB发出对于程序数据的请求时，EJB会创建这个传输对象，将它的各个域赋以相关的数值，并将整个对象传送给用户。
当EJB使用传输对象的时候，用户可以通过仅仅一次方法调用来取得整个对象，而不是使用多次方法调用以得到对象中每个域的数值；由于传输对象是通过值传递而交送给用户的，所以所有对于该传输对象的调用或取值都是本地调用，而不是远程方法调用。不过需要注意的是，这个传输对象必须具有对应于每个属性的访问方法，或者将所有属性都设为公共的。
类图13表示了传输对象模式的体系结构。
图13 传输对象类图
在图13中，传输对象首先在EJB中创建，然后返回给远程客户；当然，传输对象也可以根据需要融合其他的设计模式。
图14显示了传输对象模式中的参与模块和它们之间的交互。
图14 传输对象序列图
下面我们说明一下传输对象模式的各个参与模块：
(1)客户(Client)。客户代表了EJB所提供服务的使用者，通常是运行于用户终端的应用程序。
(2)业务对象。业务对象表示在一个模式中由会话bean、实体bean或数据访问对象(Data Access Object)实现的角色。业务对象通常负责创建传输对象，并根据请求将其传送到相关的用户；业务对象也可以从用户中取得一个传输对象格式的数据，并应用这些数据来执行一些更新。
(3)传输对象。传输对象是一个可序列化的Java对象。在这个对象的类中，通常会有一个包含所有域的构造函数，用来创建这个传输对象。
这个传输对象中的成员变量基本都被定义为公共，从而无需为它们提供相关的访问方法。当然如果存在一定安全的需要，相关的成员变量也可以设为保护或私有，并且给定各自的访问方法。由此可见，传输对象的设计是随着应用系统的需要不同而改变的，是否将对象中的成员变量设为公共，或提供一定的访问方法，将是一个很重要的设计问题。
通常在实现这个模式时，最多采取的是可更新的传输对象策略和多传输对象策略。 在可更新的传输对象策略中，传输对象不仅可以从服务于用户的业务对象中取得相关信息和数据，还可以从业务对象中得到用户对于数据所需要进行的改变。
图15以类图表的形式表明了业务对象和传输对象之间的关系。
图15 可更新传输对象类图
业务对象创建了传输对象。而用户通过访问业务对象，既得到了所需的信息，也对相关数据做出了一定的修改；为了能够使得用户可以修改业务对象各个域的取值，这个对象必须提供一定的变值方法，而出于对Web负担的考虑，业务对象所提供的方法最好以传输对象为参数。相应地，这些方法可以去调用传输对象所提供的方法，来设置传输对象的各个成员变量的取值；同时在传输对象的方法中，我们也可以植入数据验证和完整性检查的逻辑，这样在用户从业务对象的方法得到传输对象时，可以直接调用传输对象的成员方法进行本地数据访问，当然这种本地数据访问不会影响到业务对象。
当用户调用业务对象的变值方法时，该方法会将用户端的传输对象序列化，再将它发送给业务对象；业务对象接收到更新的传输对象，便将这些更新写回到自己的对象拷贝中去； 这里需要说明的是，上面提到的写回只是涉及到被更新的变量，而不是全部变量的写回，因此我们需要在传输对象中另设置一个变量，来指定哪些成员变量被用户更新过，这也就使得这种模式的设计相对复杂，开发人员需要考虑同步化和版本控制的问题。
图16显示了这个更新过程的序列图。
图16 可更新传输对象序列图
多传输对象的方法是指一个单一的业务对象可以根据用户请求制造多个不同的传输对象。也就是说，业务对象和它所创建的传输对象保持一对多的关系。类图17表示了这种实现方法的各个参与模块以及它们之间的调用关系。
图17 多传输对象类图
当一个用户需要A类型的传输对象时，他会激活相关EJB的getDataA()方法来取得传输对象A；当他需要B类型的传输对象时，他会激活getDataB()方法来获取传输对象B；依此类推。序列图18表示了这一过程。
图18 多传输对象序列图
使用这种设计模式，应用系统的实体bean及其远程接口会变得十分简单。实体bean中无需再为每一个成员变量都实现一个set()和get()方法，并在远程接口中实现相应的定义。用户无需再进行多次的方法调用来取得信息和数据，所需要的只是一次方法调用以获得整个传输对象。当然这里需要考虑Web负担和大量数据一次传输的权衡。开发人员可以根据不同的需要来选择不同的实现方法。
如上所述，用户和实体bean之间可以通过在一次方法调用中使用传输对象而交换所有的数据，也就是说传输对象作为数据载体工作，并减少了远程的方法调用，从而大大减轻了Web负担。通过使用传输对象的方法，我们也将有可能减少实体bean和其传输对象间的代码重复。不过在使用可更新的传输对象方法时，用户可以修改其本地的传输对象，之后再将其传送回业务对象中，后者将所需的更新整合到自己一端；但是这样一来，就会存在一个版本控制的问题，不同的客户可能在同时修改相同类型的传输对象，而如果相关的业务对象没有发现这一点的话，可能就会造成一些用户的数据没有得到及时更新，而另外一些用户的数据又被覆盖的情况；在系统设计中必须考虑这个问题。
8、截取过滤器
截取过滤器(intercepting filter)主要用于对于用户请求的之前处理和之后处理，也就是说它对于客户的请求使用了额外的操作。比如说，servlet可以处理一个网站的所有客户请求并提供一个核心的认证机制。
这种模式主要工作于表示层，负责处理不同类型的请求，同时也需要进行多种不同的处理。在这些请求中，有一些请求会直接传送给后端模块处理，而另外一些请求则先会在过滤器里解释或补充内容，之后才能传送给后端模块。这种模式的提出主要是由于一个客户的Web访问和系统响应都需要一定的预处理和后处理，例如用户身份、用户环境信息、用户请求的合法性等。通常这些处理的结果都会决定用户的请求是否能够进行，或是系统的响应应该用什么格式来表示。
对于这种预处理和后处理问题，传统上，开发人员会设计一系列额外的检测程序模块，也就是一整套if/else语句，并且指定如果其中任何一个检测失败，所有的处理工作都会退出。显然，这种方法是存在很大弊端的，即代码的可读性、可维护性都会被大大降低，同时将检测工作融于一般的程序模块，使得整个程序的模块性难以保证。
解决这种问题的关键在于，设计一种简单的技术，以能够添加或移除额外处理的模块，而这些模块通常都能够完成一定的检测和过滤功能。根据以上的讨论，J2EE研究人员提出了设计模式----截取过滤器作为解决方案，这种模式可以在不影响核心处理模块的情况下，实现可插入的过滤器来执行一般的处理功能。
从理论上来说，这种过滤器可以截取客户请求和系统响应，并进行相应的预处理和后处理；同时开发人员也可以随时根据需要移除这些过滤器，并不用担心会改变任何其他模块。
我们这里所说的预处理和后处理功能，通常是指一些基本的系统服务，如安全、登录，系统调试等。执行这些功能的过滤器通常是需要与核心模块分开的，并且由于系统职能或规则的变化，这些模块随时可能被添加或删除。
下面提供一些关于截取过滤器的图示，以帮助大家更好地理解这种设计模式，并合理地加以运用。图19表示了截取过滤器模式的整体结构，图19显示了截取过滤器中的参与模块和相互之间的联系。
图19 截取过滤器模式
图20 截取过滤器序列图
下面我们分别来说明图20中的各个模块：
(1)过滤管理器(Filter Manager)。过滤管理器负责过滤器的主要处理工作，即创建过滤器链对象以及相应的过滤器组建，并初始化整个处理过程。
(2)过滤器链(Filter Chain)。过滤器链是一组互不依赖的过滤器有序集合。
(3)过滤器1，过滤器2，过滤器3(FilterOne，FilterTwo，FilterThree)。这些都是提供不同服务的过滤器，而过滤器链则负责它们的协调工作。
通过采用这种设计模式，应用系统可以取得更方便的中心控制，这是由于过滤器可以提供处理多种请求的中心模块，并能根据后端的处理模块而解释和润色用户的请求，使得该请求能更好地与处理模块所提供的功能匹配。另外，过滤器通常可以将不同种类的服务聚集在一起，并提供相当灵活的服务组合，应用系统可以通过使用截取过滤器提高其重用性，过滤器可以随时根据需要从其他程序模块中插入或移除，并且由于它们通常具有标准的接口，开发人员可以使用一组类似的过滤器，并在不同的情况下进行全组的重用。
采用这种设计模式也会带来一定的问题，即在过滤器之间共享信息将变得非常困难，这是由于根据其定义和需求，每个过滤器的设计和开发都大相径庭。因而如果在不同的过滤器之间需要共享信息的话，其代价将是非常昂贵的。
作者：务实，多年从事J2EE网站及应用系统项目的开发和应用。
参考资料：
《J2EE设计开发编程指南》 Rod Johnson 电子工业出版社
《J2EE参考大全》 Jim Keogh 电子工业出版社
《实用J2EE设计模式编程指南》 Craig A.Berry 电子工业出版社
