J2EE业务层模式--传输对象组装器

问题：

  需要获取一个应用模型，但是这个模型中包括了来自多个不同组件的传输对象。

  应用系统的客户端经常需要从业务层获取业务数据，然后要么这些数据显示出来，要么执行一些中间处理。应用模型代表着封装在业务层业务组件中的业务数据。如果客户端需要应用模型数据的话，就必须从各不同的数据源(比如业务对象、数据访问对象、应用服务以及业务层的其他对象)中定位、访问或者模型的各个部分。这种做法会产生以下几个问题：

--如果让客户端直接访问一个层次中的组件，就会在不同层次之间造成耦合。由于这种紧耦合的存在，如果修改了业务层的组件，也就会在各个客户端中间产生连锁反应。客户端代码复杂性也增加了，因为客户端必须要和多种业务组件交互，并且那些用于构造应用模型的业务逻辑也被放进了客户端代码中。

--另外，不同的客户端为了获取、构造模型的数据，都要实现一些相似的逻辑，这也增加了系统维护的工作量。如果客户端访问业务组件式分布式的远程组件，那么性能也会随之下降，因为客户端必须越过网络访问多个业务组件才能获得全部的业务模型数据。

   约束：

   要集中封装业务逻辑，避免在客户端实现这些逻辑

   在构造业务层对象模型的数据时，尽量减少对远程对象的网络调用。

   创建一个复杂模型，并交给客户端，用于界面的显示

   要对客户端隐藏模型实现的复杂性，而且还想降低客户端与业务组件之间的耦合。

解决方案：

  使用传输对象组装器，以复合传输对象的形式构件应用模型。传输对象组装器从各种不同的业务组件和业务服务中聚合多个传输对象，并且最后把复合传输对象返回给客户端。

  传输对象组装器从业务组件中获取传输对象，然后，传输对象组装器对这些传输对象进行处理，创建并组装一个体现了应用模型数据的复合传输对象。客户端使用传输对象组装器来获取只读的应用模型，以供显示或者其他中间处理之用。客户端并不修改复合传输对象中的数据。

  前面讲过，业务对象也能够使用封装在它本身中的数据生成复合传输对象。另一个方面传输对象组装器则从不同多种数据源<比如业务对象、会话门面、应用服务、数据访问对象以及其他各种服务>获取数据。传输对象组装器可以使用服务定器来定位业务服务组件。

效果：

1、分离了业务逻辑，简化了客户端逻辑

   如果客户端包括一些与分布式组件交互的处理逻辑，那么就很难清晰的把业务逻辑同客户端层截然分开来。传输对象组装器包含了用于维护对象关系的业务逻辑，以及用于构造符合模型的复合传输对象的业务逻辑，这样客户端就不需要知道如何构造模型，也不需要了解为这个复合模型提供数据的多个组件。

2、减少了客户端和应用逻辑之间的耦合

  传输对象组装器对客户端隐藏了构造模型数据的复杂性，降低了客户端和模型之间的耦合，在这种松耦合的情况下，如果模型发生了变化，只需要传输对象组装器相应的改变就OK乐，这样一来，就能对客户端隐藏模型的这种变化。

3、提高了系统的网络性能

传输对象组装器减少了从业务层获取应用模型所需的调用次数，因为通常只需一次方法调用就能获取应用模型。但是这个复合传输对象可能包含大量的数据。这也就意味着，虽然使用传输对象组装器能够减少网络调用次数，但是一次调用中传输的数量增加了，在使用这个模式的时候，应该权衡考虑这个代价。

4、提高了客户端的性能

服务器端的传输对象组装器无需使用任何客户端的资源，就能以复合传输对象的形式构造模型数据。在组装模型的过程中，客户端没有消耗任何资源。

5、可能会引入失效的数据

传输对象组装器按照需要，以复合传输对象的形式构造应用模型，而数据来源则是业务模型当前撞期的一个快照。客户端获得了复合传输对象之后，这个对象就在客户端本地上了，与原本的数据之间不存在网络联系，所以，如果在业务组件发生了后续改动，这种改动也不会传播到客户端的应用个模型数据上。因此这些应用模型数据在客户端获取之后可能会失去时效性。