JafTalks

With the evolution of technologies and software systems, applications and their interfaces had become more interactive leading to make the concerns of solution architects more critical.

Performance is one of these concerns, responding in real time to the users requests became critical especially in web and network based applications.

Service Oriented Architecture is widely spread now because it maintains an acceptable level of interactivity in the presentation layer of rich internet applications, and assures an acceptable level of distribution in the data layers.

In this kind of applications and in order to respond to a user request you may need to do multiple calls to a remote service that will clearly affect the performance and which depends on obvious factors: latency and Throughput.

Latency describes the time needed to reach the remote service, while throughput describes the amount of data sent over network in a certain time (1 second for example). In new systems, new routing servers, and HTTP servers capabilities the throughput became negligible while the latency remains the main factor.

In order to enhance performance in a Service Oriented Application, we have to reduce latency, in another meaning we have to reduce the number of remote calls to the server.

A response to a user request should be done with minimum possible access to the remote service (1 call in the majority of cases) and in order to do that we have to send all the needed parameters to the server and get all the data in one shot, the parameters should be encapsulated in one abject and the result in another one, this object will be named Data Transfer Object.

DTO can be simple object or a collection of object where individual objects can be easily retrieved through a key or an index. A DTO shouldn’t include any business logic to simplify its transfer over network.

The utilization of DTOs may introduce other dependency issues, which can be solved by separating DTOs from the domain objects. Domain Objects don’t have to know about DTO and vice versa. This can be done by establishing an assembler which creates a DTO based on a domain object and update domain objects based on DTO.

DTOs are collections, datasets, datatables or other SDKs including entities that make their testability easier and simpler.

In consequence, architects can enhance their applications performance by reducing the number of calls to remote services using DTOs, but their utilization may require more computing and additional coding work, and like every design pattern or architectural concept we have to be pragmatic with it, it may apply in a situation while it can be an overload in another situation. This depends on the application and business scenario, we should always balance between the non functional requirements, the quality indicators and the intended results.

Dear reader, do you think that DTO will make the developer’s life easier by enhancing the applications performance and structure, or it will make it complex by adding more coding work and rules?

Personally I adore design patterns, and I loved this one too!