Architectural pattern - data transfer object.

-

Background –

There are many angles you can look into performance issue. Many times we get complains that, your app is slow. One of the major area to look into performance improvement is inter process communication, sending data between two processes in client-server architecture is a costly operation, because many calls are synchronous (where client wait server to give processed data back) and even if it is asynchronous,  time taken to transfer data matters.

One way to solve this problem is to reduce the number of calls between two processes, and pass more data whenever we are calling inter process methods, but for that we shall have well-defined interface with long list of method parameters. This approach is not very good because first, we have to very careful with the sequence of parameter while calling it (If we have 7 ints in function parameter list, as all take same type of parameter if you miss the sequence, it could lead to wrong result) second, doesn’t matter how much information you pass to any function it will return only one result from server side (We can return only single value from function).

A good solution is to create a data transfer object (DTO) that will hold all necessary information which are required to call remote method. Make function signature to accept data transfer object and function shall return processed data transfer object back to client. Then client will query all required data from DTO object locally.

For example, let’s think about a client-server architecture for a simple banking application. Without DTO object, it has to query all information from server.



But after we have customer DTO, we will call server only once and query all required data from DTO locally.


class BankCustomerDTO
{
    public:
        
    private:
        string m_accountNumber;
        string m_name;
        string m_pan;
        double m_balance;
        string m_debitCardNumber;
        string m_branchAddress;
}



DTO will not have any business logic in it, except store and retrieve data. It has to be a plain data class. 

About Data transfer object architectural pattern –

At some places we call it value object (VO). At first place, you may think that DTO has reduced the performance, as it is one indirection between client and server, and now call has to go throw DTO to server, before it was direct call to server. But the amount of remote call reduction matters, it will give good performance eventually as you will reduce inter process method calls. Remember remote calls are very costly.


Thanks for reading it. To read more on design patterns and basic design principles please see my web page. You can also join me on FB or on G++. Please drop comments for any question related to this blog.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post clean...
Read more

Factory method design pattern for beginners.

-
Image
Background - First, let me ask a simple question. Do you really think that "factory method design pattern comes because we had an issue with creating objects? Or it is only for creating objects? Or why we need a factory to create an object when we can create it through constructor? The answer is NO! Each class is capable of creating objects on its own. Through constructor (until and unless you have not put constructor in private).  Then why we need factory at all? Is there something like, without Factory method, I am not able to create my software? No, we can create objects without it, then why we are using it very extensively? Remember one thing, programming languages are very powerful . W e can build software without following any design principles. But then, it will be poor in some of these areas -  Maintainability. Extend-ability. Performance. Security. Robust. and many more... Developers have been developing...
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one...
Read more