J2EE体系结构设计（中）

图5视图帮助序列图 
  这里我们对于序列图中的各个元素加以简单的介绍：

  (1)视图(view)。视图负责向用户展示动态数据信息，而帮助类则负责支持视图的工作，即打包和建立相应的数据模型。

  (2)帮助类(helper)。一个帮助类负责帮助视图或控制器完成相关的处理工作，包括收集数据、存储中间模型等；帮助类也可以在保证数据完整性和准确性的情况下，为不同显示需求修改数据模型，也就是说，根据用户的请求，帮助类可以向视图提供未经处理的原始数据，或是已经格式化后的Web内容；一个视图同时可以和多个帮助类协同工作，而后者通常是由JavaBeans和标记(tag)实现的。

(3)值bean(ValueBean)。值bean实际上是用于存储中间数据模型的帮助类的另一种叫法，例如在序列图5中，business service就根据请求返回了一个值bean。

  (4)业务服务(business service)。业务服务是指用户试图得到的，应用系统可以提供的相关服务；通常来说，业务服务可以通过一个业务代表(business delegate)来访问，而后者主要是提供对于业务服务的控制和保护。

  在应用系统的视图模块中使用帮助类可以将不同的程序逻辑很好地分离开来，并在视图模块之外为开发人员提供设计程序逻辑的空间；基于JavaBean和标记(tag)所开发的帮助类通常都可以被多个视图模块重用，因此也提高了组件的重用性和可维护性；把显示逻辑从数据处理逻辑分离出来，也有利于开发团队中角色及人物的划分；比如说，如果各种程序逻辑过于结合的话，软件开发人员可能需要在HTML，网页中修改代码而Web设计师则需要在处理数据访问的JSP中修改页面布置，这些情况都可能会导致系统设计和开发中由于不同技术人员的介入，而产生相关的问题。

5、会话面 

  这种设计模式出现的背景在于EJB通常既包括程序数据，又包括程序逻辑，而这些代码都会通过一定的界面作用于客户层，在多层次的J2EE平台应用程序中，就会造成一定的困难。

  具体来说，在J2EE平台上的多层次系统中，通常会存在以下的问题： 
  (2)在客户和服务器之间有多次方法调用，因而导致了Web性能方面的问题； 

  为了解决以上的问题，开发人员可以采用会话面的设计模式，即使用会话bean来实现一个面(facade)来包含一个工作流中所有相关对象的交互；这个会话面负责管理业务对象，并向用户提供一个统一的服务访问层，会话面可以面向底层对象的交互过程，并提供一个仅仅包含必须提供的接口的服务层，由此它将复杂的对象交互和用户之间隔离开来；  会话面也负责管理企业数据和企业对象之间的交互，并表达其中需要的企业逻辑，因此会话面也可以管理企业对象之间的作用关系；同时，根据工作流的需要，会话面也管理对象的创建、查找、修改和删除。
  在一个复杂的应用系统中，会话面可以将其生命周期的管理下放到一个单独的帮助对象去，比如说，会话面可以将管理会话和实体bean生命周期的工作交给服务定位对象；  同时，在应用系统中，检查业务对象之间的作用关系也是非常重要的，一些关系可能是暂时的，即只使用于一定的交互过程，而另外一些关系则是永久的，暂时的关系适合建模于会话面中的工作流，永久的关系则需要具体情况具体分析。

  图6中的类图简要描述了会话面的设计模式，图7给出了会话面的序列表示，即参与组件及其交互关系。

 

 

 

图7会话面序列图 ||| 
这里我们对于图7的各个组件加以简要的介绍： 

  (2)会话面(Session Facade)。会话面通常是用会话bean来实现的，它管理着多个企业对象的作用关系并提供一个高层次的抽象界面给用户。

  (3)业务对象(Business Object)。业务对象是一个可以使用多个不同设计方案的对象，例如会话bean、实体bean和数据访问对象。在图6中业务对象负责提供数据和服务，而会话面则需要与多个业务对象实例交互而获得相应的服务。

   会话面实际上就是业务层的一个控制对象，它负责控制用户与企业数据和企业服务对象之间的交互；在一个复杂的应用系统中，甚至可能会有多个会话面作为用户和对象模块之间的中介。

  下面介绍两种实现会话面的常见方法。 
  在实现会话面的时候，首先应该决定是用状态化还是无状态的会话bean来实现，这主要取决于会话面所建模的业务流程；如果一个业务流程只需要一次方法调用就可以实现其服务，那么就可以使用无状态的会话bean来实现它。

  (2)状态化的会话面 

  通过在应用系统中采用会话面的设计模式，将在系统中得到以下的收益： 
  ②减少暴露给用户的企业对象，从而降低它们之间的依赖关系； 
6、 数据访问对象 

  这种模式出现的背景在于数据访问的逻辑极大程度上取决于数据存储的格式，比如说关系型数据库、面向对象数据库、磁盘文件等。

  目前大部分的J2EE应用程序都需要在一定程度上使用可持久性的数据，而实现持久性数据的方法因应用程序不同而异，并且访问不同存储格式数据的应用程序接口(API)也有着显著的差别；有的时候，应用程序还会访问存储在不同操作平台上的数据，这使得问题更为复杂，通常，应用程序会使用共享的分布式组件，如实体bean来表达持久性数据。应用程序可以使用bean管理的持久性实体bean，而在实体bean中植人数据访问逻辑，或者使用容器管理的持久性实体bean，从而使容器管理所有的事务和持久性细节；而如果应用程序对于数据访问的需求十分简单的话，也可以采用会话bean或Servlet直接访问持久性存储来读取和修改数据。

  一些应用程序可以使用JDBC应用程序接口来访问关系数据库中的数据，JDBC负责一般的持久性数据访问和管理，在J2EE应用程序中，JDBC中可以嵌入SQL语句，用以访问关系型数据库，当然根据数据库类型的不同，SQL语句的词法和语法也会有所不同；需要说明的是，当数据存储格式不同的时候，数据访问逻辑的区别就更加明显了，例如关系型数据库、面向对象数据库和磁盘文件，各自数据的访问逻辑各有千秋，这样一来就造成了程序代码和数据访问代码之间的依赖关系；当程序组件，即实体bean、会话bean或servlet、JSP等需要访问数据源时，它们会使用正确的应用程序接口来得到连接并管理数据源，但这样也会造成这些组件与数据源物理实现之间的依赖关系，从而使得应用程序很难从一个数据存储实体移植到另一个数据存储实体中去；当数据源的物理实现变化的时候，应用程序也必须相应地加以改变。

  基于以上所讨论的问题，开发人员开始采用数据访问对象的方法。数据访问对象实际上就是包含对于所有数据访问逻辑的对象，并管理着对于数据源的连接，根据数据源的不同，数据访问对象实现了不同的访问机制，这里所说的数据源可以是持久性存储介质，如关系型数据库，也可以是外部服务，如B2B的数据交换；不仅是用户，而且包括应用系统中的其他组件，也可以使用数据访问对象所提供的数据访问接口，数据访问对象将数据源的物理实现细节与其用户完全分离开来，并且在底层数据源变化的时候，数据访问对象向用户提供的接口是不会变化的；这种方法使应用系统使用数据访问对象时可以适应多种数据存储介质，总之，数据访问对象就是系统组件和数据源中间的适配器。

图8中的类图表示了数据访问对象设计模式的参与对象和之间的调用关系，图9是这种设计模式的序列图。 

 

 

图9 数据访问对象序列图 ||| 
对于图9序列图中的组件加以解释 

  (2)数据访问对象(Data Access Object)。数据访问对象是这种模式中的主题，它提供了底层数据访问的对象，并将其提供给业务对象以使得后者能够透明地访问数据源；同时业务对象也将数据的加载和存储操作移交给数据访问对象处理。

  (3)数据源(Data source)。这里指的是数据源的物理实现，这个数据源可以是一个数据库，包括关系型数据库、面向对象数据库或文件系统。 

  下面给出几种实现数据访问对象设计模式的方法。   
  既然每一个业务对象都对应于一个数据访问对象，那么开发人员就可以建立业务对象、数据访问对象和底层实现的关系；一旦这种关系建立起来，开发人员就可以为所有的数据访问对象编写特殊的代码生成工具。

  生成数据访问对象的信息通常存储在一个开发人员定义的描述文件中，如果对于数据访问对象的要求过于复杂，开发人员可以考虑使用第三方工具来为关系型数据库提供对象对关系的映射。这些工具通常是一些GUI程序，可以用来将业务对象映射为持久性的存储对象，并定义中间运作的数据访问对象，在映射完成的时候，这些工具可以自动地生成代码，并提供一些相应的功能，如缓存结果、缓存查询、与应用服务器整合、与第三方产品整合等。

  当底层的数据存储不会轻易改变的时候，开发人员可以采取这种方法来实现相应的，数据访问对象，图10是这种方法的类图。 

 

  当底层的数据存储可能会变化的时候，开发人员可以采用抽象代理的方法来实现数据访问对象；抽象代理的方法会创建一些虚拟的数据访问对象代理和各种类型的实际数据访问对象代理，每种对象对应一种持久性存储介质的实现，一旦组件得到这些代理，就可以利用来创建需要使用的数据访问对象。

  图11给出了这种情况的类图。该类图表示了一个基础的数据访问对象代理，它是一个抽象类，被其他一些实际的数据访问对象代理继承以支持特定的数据访问函数；用户可以得到一个实际的数据访问对象，并利用它来创建需要的数据访问对象而访问相关的数据，每一个实际的数据访问对象都负责建立对于数据源的连接，并得到和管理所支持的业务数据。 

 

图11  抽象代理使用DAO 

 

这种设计模式的优势： 

可移植性好。在应用系统中添加数据访问对象，可以使得前者能够很方便地移植到另外一种数据库实现上。业务对象与数据实现是隔离的，所以在移植过程中，仅仅对数据访问对象进行一些变化即可。

减少业务对象的代码复杂度。由于数据访问对象可以管理所有的数据访问复杂细节，这也就简化了业务模块和其他数据客户的代码。同时也提高了应用系统的整体可读性和开发率。

集中处理所有数据访问。由于所有的数据访问操作都移交给数据访问对象，这样应用系统其他部分就与数据访问实现隔离开来，而全部相关操作都与数据访问对象集中处理，这样也使得相关操作更加容易被维护和管理。

这种设计模式的缺陷： 

添加了额外的层面。数据访问对象在数据用户和数据源之间添加了一个层面，也就增加了一些额外的设计和实现的负担。当然，我们认为它是物有所值的。

总之，在开发人员选择不同模式的时候，应该注意，一定的模式对应于一定的应用层次。比如说，与视图和显示相关的模式就是在Web层应用的。而一些与业务逻辑控制相关的模式则是与EJB层次相关的。另外一些关于读取数据和分派操作的模式则适用于不同的层次之间。

7、值对象或传输对象 

  这种设计模式的出现是基于客户需要与ejb大量地交换数据的情况。具体来说，在J2EE平台中，应用系统通常将服务器端的程序组件实现为会话bean和实体bean，而这些组件的部分方法则需要将数据返回给客户；这种情况下，通常一个用户会重复调用相关方法多次，直到它得到相关信息，应该注意的是，多数情况这些方法调用的目的都是为了取得单一的信息，例如用户名或者用户地址等。

  显而易见，在J2EE平台上，这种调用基本上都是来自远程的。也就是说，用户多次调用相应的方法会给Web带来极大的负担，即使用户和EJB容器加载相同的JVM、OS和计算机上运行EJB程序，由于方法调用被缺省地认为是远程任务，所以这种问题依然存在。

  由于以上所提到的问题，在远程方法的调用次数增加的时候，相关的应用程序性能将会有很大的下降，因此利用多次方法调用而取得单一的信息是非常低效的；在这种情况，J2EE的研究人员建议使用传输对象来包含所有的程序数据，即每次方法调用可以发送和接收这个传输对象；当用户向EJB发出对于程序数据的请求时，EJB会创建这个传输对象，将它的各个域赋以相关的数值，并将整个对象传送给用户。 

  当EJB使用传输对象的时候，用户可以通过仅仅一次方法调用来取得整个对象，而不是使用多次方法调用以得到对象中每个域的数值；由于传输对象是通过值传递而交送给用户的，所以所有对于该传输对象的调用或取值都是本地调用，而不是远程方法调用。不过需要注意的是，这个传输对象必须具有对应于每个属性的访问方法，或者将所有属性都设为公共的。