J2EE体系结构设计（2）

核心提示：当底层的数据存储可能会变化的时候，开发人员可以采用抽象代理的方法来实现数据访问对象；抽象代理的方法会创建一些虚拟的数据访问对象代理和各种类型的实际数据访问对象代理，J2EE体系结构设计（2），每种对象对应一种持久性存储介质的实现，一旦组件得到这些代理，我们也将有可能减少实体bean和其传输对象间的代码重复，不过在使用可

　　当底层的数据存储可能会变化的时候，开发人员可以采用抽象代理的方法来实现数据访问对象；抽象代理的方法会创建一些虚拟的数据访问对象代理和各种类型的实际数据访问对象代理，每种对象对应一种持久性存储介质的实现，一旦组件得到这些代理，就可以利用来创建需要使用的数据访问对象。
　　
　　图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和其传输对象间的代码重复。不过在使用可更新的传输对象方法时，用户可以修改其本地的传输对象，之后再将其传送回业务对