表示层模式:Transfer Object Assembler—传输对象组装器模式

Context
In a Java 2 Platform, Enterprise Edition (J2EE) application, the server-side business
components are implemented using session beans, entity beans, DAOs, and so forth.
Application clients frequently need to access data that is composed from multiple objects.
Problem
Application clients typically require the data for the model or parts of the model to
present to the user or to use for an intermediate processing step before providing some
service. The application model is an abstraction of the business data and business logic
implemented on the server side as business components. A model may be expressed as a
collection of objects put together in a structured manner (tree or graph). In a J2EE
application, the model is a distributed collection of objects such as session beans, entity
beans, or DAOs and other objects. For a client to obtain the data for the model, such as to
display to the user or to perform some processing, it must access individually each
distributed object that defines the model. This approach has several drawbacks:
Because the client must access each distributed component individually, there is a
tight coupling between the client and the distributed components of the model over the
network
The client accesses the distributed components via the network layer, and this can
lead to performance degradation if the model is complex with numerous distributed
components. Network and client performance degradation occur when a number of
distributed business components implement the application model and the client directly
interacts with these components to obtain model data from that component. Each such
access results in a remote method call that introduces network overhead and increases the
chattiness between the client and the business tier.
The client must reconstruct the model after obtaining the model's parts from the
distributed components. The client therefore needs to have the necessary business logic to
construct the model. If the model construction is complex and numerous objects are
involved in its definition, then there may be an additional performance overhead on the
client due to the construction process. In addition, the client must contain the business logic
to manage the relationships between the components, which results in a more complex,
larger client. When the client constructs the application model, the construction happens on
the client side. Complex model construction can result in a significant performance
overhead on the client side for clients with limited resources.
Because the client is tightly coupled to the model, changes to the model require
changes to the client. Furthermore, if there are different types of clients, it is more difficult
to manage the changes across all client types. When there is tight coupling between the
client and model implementation, which occurs when the client has direct knowledge of the
model and manages the business component relationships, then changes to the model
necessitate changes to the client. There is the further problem of code duplication for model
access, which occurs when an application has many types of clients. This duplication makes
client (code) management difficult when the model changes.
Forces
Separation of business logic is required between the client and the server-side
components.
Because the model consists of distributed components, access to each component is
associated with a network overhead. It is desirable to minimize the number of remote
method calls over the network.
The client typically needs only to obtain the model to present it to the user. If the
client must interact with multiple components to construct the model on the fly, the
chattiness between the client and the application increases. Such chattiness may reduce the
network performance.
Even if the client wants to perform an update, it usually updates only certain parts of
the model and not the entire model.
Clients do not need to be aware of the intricacies and dependencies in the model
implementation. It is desirable to have loose coupling between the clients and the business
components that implement the application model.
Clients do not otherwise need to have the additional business logic required to
construct the model from various business components.
Solution
Use a Transfer Object Assembler to build the required model or submodel. The
Transfer Object Assembler uses Transfer Objects to retrieve data from various business
objects and other objects that define the model or part of the model.
The Transfer Object Assember constructs a composite Transfer Object that represents
data from different business components. The Transfer Object caries the data for the model
to the client in a single method call. Since the model data can be complex, it is
recommended that this Transfer Object be immutable. That is, the client obtains such
Transfer Objects with the sole purpose of using them for presentation and processing in a
read-only manner. Clients are not allowed to make changes to the Transfer Objects.
When the client needs the model data, and if the model is represented by a single
coarse-grained component (such as a Composite Entity), then the process of obtaining the
model data is simple. The client simply requests the coarse-grained component for its
composite Transfer Object. However, most real-world applications have a model composed
of a combination of many coarse-grained and fine-grained components. In this case, the
client must interact with numerous such business components to obtain all the data
necessary to represent the model. The immediate drawbacks of this approach can be seen in
that the clients become tightly coupled to the model implementation (model elements) and
that the clients tend to make numerous remote method invocations to obtain the data from
each individual component.
In some cases, a single coarse-grained component provides the model or parts of the
model as a single Transfer Object (simple or composite). However, when multiple
components represent the model, a single Transfer Object (simple or composite) may not
represent the entire model. To represent the model, it is necessary to obtain Transfer Objects
from various components and assemble them into a new composite Transfer Object. The
server, not the client, should perform such "on-the-fly" construction of the model.