Data transfer object (data transmission object) [reprint]

Data transfer object (data transmission object) released on: 4/1/2004 | updated on: 4/1/2004

Data transfer object (data transmission object)

Version: 1.0.1

Content on this page

	Context
	Problem
	Influencing Factors
	Solution
	Example
	Test considerations
	Security considerations
	Result Context
	Related Mode
	Thank you

Context

You are designing a distributed application. To meet a single client request, you find that you have made multiple calls to a remote interface, the response time of these calls exceeds the acceptable level.

Back to Top

Problem

How can we retain the simple semantics of the process call interface without being affected by the inherent lag time of remote communication?

Back to Top

Influencing Factors

Consider the following considerations when communicating with remote objects:

?	Remote calls (those that must span the network) are slow. Although many remote call frameworks can hide the complexity of remote calls, they cannot eliminate the steps required for communication. For example, you must first locate the Remote Object Location and establish a connection with the remote computer before serializing the data into a byte stream, and then encrypt the data before it can be transmitted to the remote computer.
?	When considering network performance, you must consider both the latency and throughput. In short, the "lag time" describes the time elapsed before the first byte of the data reaches the destination. "Throughput" describes the number of bytes of data sent over the network within a certain period of time (for example, 1 second. In modern networks (such as the Internet) based on IP routing, latency can be a factor greater than throughput. This means that the time used to transmit 10 bytes of data may be almost the same as the time used to transmit 1,000 bytes of data. This effect is particularly significant when no connection protocol (such as HTTP) is used. Generally, the faster the network speed can increase the throughput, but it is more difficult to reduce the lag time.
?	When designing an object interface, a good way is to hide a large amount of information in the object and provide a set of fine-grained methods to access and operate on the information. "Fine-grained" means that each method is responsible for a single, fairly small, and basic functional unit. This method simplifies programming and provides better abstraction within the object, thus increasing the possibility of reuse. You must make a balance between the following facts: using a finer-grained method means that you need to call more methods to execute high-level tasks. In general, the overhead for calling these extra functions is acceptable when calling methods within the same process; however, the overhead may become unacceptable when calling these methods across processes and network boundaries.
?	The best way to avoid latency problems inherent in remote calls is to make fewer calls and send more data to each call. One way to do this is to declare the remote method using the long parameter list. In this way, the client can pass more information to the remote component in a single call. However, this will make programming for this interface prone to errors, because the program may only call the parameters of the external method according to the position in the call statement. For example, if the remote method accepts 10 string parameters, it is easy for developers to PASS Parameters in the wrong order. The compiler will not be able to detect such errors.
?	The long parameter list does not help to return more information from a remote call to the client, because most programming languages limit the return type of a method call to a single parameter. Coincidentally, a large amount of information is often returned when most data is transmitted. For example, many user interfaces transmit a small amount of information but want to return a large amount of result data.

Back to Top

Solution

Create a data transmission object (DTO) that contains all the data required for remote calls. Modify the remote method signature to accept DTO as a single parameter and return a single DTO parameter to the client. After the caller's application receives DTO and stores it as a local object, the application can independently call DTO without causing Remote Call overhead.Martin FowlerInPatterns of enterprise application architectureThis mode is described in [fowler03.

Displays how client applications perform a series of remote calls to retrieve each element of a customer name.

Figure 1:NoDtoRemote Call

Dto allows remote objects to return the entire customer name to the client in a single remote call. In this example, the number of calls is reduced from 4 to 1. The client performs a single call and then interacts with DTO locally without Multiple Remote calls (see figure 2 ).

Figure 2:UseDtoReduce the number of calls

DTO is a simple set of containers that need to transmit aggregated data across processes or network boundaries. It should not contain business logic and restrict its behavior to activities such as internal consistency checks and basic verification. Note that DTO depends on any new class instead of implementing these methods.

When designing a data transmission object, you have two main options: Use a general set; or use an explicit getter and setter methods to create a custom object.

The advantage of a general set is that only one class is required to meet any data transmission purpose in the entire application. In addition, collection classes (such as simple arrays or hash charts) are built into almost all language libraries, so you do not have to write code for the new classes. The main disadvantage of using a collection object for DTO is that the client must access the fields in the set by location sequence number (in the case of a simple array) or element name (in the case of a key set. In addition, the set stores the same type (usually the most generalObjectType), which can cause subtle but fatal encoding errors that cannot be detected during compilation.

If you create a custom class for each DTO, You can provide strongly-typed objects that are exactly the same as any other objects and accessible by client applications. Such objects can be checked during compilation, it also supports code editor functions (such as Microsoft & reg; intelliisense & reg; technology ). The main drawback is that if the application sends many remote calls, you may have to write a lot of class code in the end.

Many methods try to combine the advantages of these two methods. The first method is the code generation technology, which can generate source code for custom DTO classes that are separated from existing metadata (such as the Extensible Markup Language (XML) architecture. The second method is to provide a more powerful set. Although it is a general set, it stores the link and data type information together with the original data. Microsoft ADO. netDatasetThese two methods are supported (see using dataset in. Net to implement data transfer object ).

With the DTO class, you need to fill it with data. In most cases, data in DTO comes from multiple domain objects. Because DTO has no behavior, it cannot extract data from the domain object. This is correct, because if DTO does not know the domain object, you can reuse DTO in different contexts. Similarly, you do not want the domain object to know DTO, because it may mean that changing DTO requires changing the code in the domain logic, which leads to a large number of maintenance tasks.

The best solution is to useCyclerMode [fowler03]. This mode can be used to create DTO with business objects or vice versa..CyclerYesMapperDedicated instances inPatterns of enterprise application architecture[Fowler03] also mentioned it.

Figure 3:UseCyclerLoad dataDtoMedium

The key feature of aggreger is that DTO and domain objects are not mutually dependent. This eliminates the mutual influence between the two objects. Disadvantage:CyclerIt depends on DTO and domain objects at the same time. Any changes to these classes may cause changes that must be made.CyclerClass.

Back to Top

Example

See use dataset in. Net to implement data transfer object.

Back to Top

Test considerations

DTO is a simple object and should not contain any business logic to be tested. However, you do need to test data aggregation for each DTO. Each DTO may need to be tested or not, depending on your serialization mechanism. If serialization is part of the framework, you only need to test a DTO. If this is not the case, use a general reflection mechanism so that you do not need to test the serialization of each DTO.

DTO is also advantageous for the testability of remote functions. By enabling the remote method results to be used in the object instance, you can easily pass the data to the test module or compare it with the required results.

Back to Top

Security considerations

Ideally, you should first filter and verify the data obtained from unreliable sources (such as user input from web pages) and place it in DTO. By doing so, we can think that the data in DTO is relatively safe, thus simplifying the future interaction with DTO.

The process that receives DTO and the security creden。 of associated users are also worth noting. Dto usually contains a large amount of information gathered from many different sources. Have you authorized all users of DTO to access all information contained in DTO? The best way to ensure that a user has been authorized is to fill DTO with only the specific data allowed by the user's security creden. Efforts should be made to prevent DTO from taking charge of its own security. This will increase the number of DTO dependencies on other classes, which means that these classes must be deployed to all nodes using DTO. This also disperses security functions into more categories, which increases security risks and negatively impacts flexibility and maintainability.

Back to Top

Result Context

Data transfer objectIt has the following advantages and disadvantages:

Advantages

?	Reduces the number of remote calls.By transmitting more data in a single remote call, the application can reduce the number of remote calls.
?	Improved performance.Remote calls can greatly reduce the running speed of applications. Reducing the number of calls is one of the best ways to improve performance. In most scenarios, the remote call time used to transmit a large amount of data is almost the same as the call time used to transmit only a small amount of data.
?	Hide internal conditions.More data can be transferred back and forth in a single call, and the internal situation of the Remote Application can be more effectively hidden behind the coarse-grained interface. This is to useRemoteThe main reason for the facade mode [fowler03.
?	Discover business objects.In some cases, defining DTO helps you discover meaningful business objects. When creating a custom class for DTO, you usually notice that the group is displayed to the user or another system as a set of cohesive information. Typically, these groups are used as useful prototypes for describing the objects in the business domains processed by the application.
?	Testability.Encapsulating all parameters in a serializable object improves testability. For example, you can read DTO from an XML file and call remote functions to test them. Similarly, you can easily serialize the results to the XML format and compare the XML document with the expected results without creating lengthy comparison scripts.

Disadvantages

?	Too many classes may be required.If you select a DTO with a strong type, you may have to create one for each remote method (if you consider the return value, it is two) DTO. Even in a coarse-grained interface, this may lead to a large number of classes. It is very difficult to write code for such a number of classes and manage these classes. Automatic code generation can alleviate this problem to some extent.
?	Increase the computing workload.If you convert a data format on the server to a byte stream that can be transmitted across the network and convert it back to the object format in the client application, it can bring a considerable overhead. Generally, data from multiple sources needs to be aggregated to a single DTO on the server. To improve the efficiency of remote calls over the network, other computations must be executed at either end to aggregate and serialize information.
?	Increase the coding workload.You can use a line of code to pass parameters to the method. Dto requires the instance to update the object and call setters and getters for each parameter. Writing this Code may be boring.

Back to Top

Related Mode

?	Remote Facade.Data transfer objectMode and coarse granularityRemote FacadeTo reduce the number of remote calls.
?	Mapper[Fowler03].MapperIt is a recommended technology to load DTO with data elements in domain objects.
?	Value Object. Some materials willData transfer objectCalledValue Object. This usage is no longer considered correct. For more information, seePatterns of enterprise application architecture[Fowler03].

For more information, see the following modes:

Back to Top

Thank you

[Fowler03] Fowler, Martin.PatternsEnterpriseApplication Architecture. Addison-Wesley, 2003.

Back to Top

Link: http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/DesDTO.mspx
Related discussions:
Http://dev.csdn.net/develop/article/24/24912.shtm
Http://www.artima.com/forums/flat.jsp? Forum = 106 & Thread = 36312 & START = 15 & msrange = 15