No More DTO
I just found Mr. Piirainen's thoughts on DTOs and it was enough for me to start writing something right now.
When people talk about "transfer" and that they need some object (assuming DTO) to do a "data transfer" I would review the need for this transfer.
DTO is very similar to Memento design pattern so DTO could be called a variation of it. Memento could be useful for saving state of some object. We create Memento if we need some kind of client-side caching where we store a local state of server-side object. See a discusion regarding DTO and caching in comments below.
But when somebody talks about the need to "transfer" some data I would suggest to get the data directly from the source! Distinquish "transfer data" and "store state". No need for a transfer - just let an object that needs the data talk to object which is responsible for holding the data. Find object who demands the data. Find object which holds the data. While in your demanding object, get the data from the direct source. This is so easy.
When people talk about "transfer" and that they need some object (assuming DTO) to do a "data transfer" I would review the need for this transfer.
DTO is very similar to Memento design pattern so DTO could be called a variation of it. Memento could be useful for saving state of some object. We create Memento if we need some kind of client-side caching where we store a local state of server-side object. See a discusion regarding DTO and caching in comments below.
But when somebody talks about the need to "transfer" some data I would suggest to get the data directly from the source! Distinquish "transfer data" and "store state". No need for a transfer - just let an object that needs the data talk to object which is responsible for holding the data. Find object who demands the data. Find object which holds the data. While in your demanding object, get the data from the direct source. This is so easy.
posted by dkrukovsky at 11:29 AM
2 Comments:
This sounds perfectly reasonable in a non-distributed environment. However, I'm not sure how well this would perform if the client is physically separate from the domain.
Many uncertainties crop up when you have a network between client and server. It gets even worse if the client is a rich one, which has individual installations on each client machine (as opposed to a web client, which is installed elsewhere in the cluster).
This is where I see DTO as a valid concept. You need to transfer data between the presentation and the domain, and the pipeline is a limited resource. You need to keep the chatter down - both in the size of individual communications, and more importantly in the number of them. Each network communication has much overhead beyond the data itself.
In this scenario, any change in the server design that affects the client means a redeploy of at least twice as many components as an isolated change (all domain deployments and all presentation deployments). Worse case is the need to SMS or otherwise force the end user to update their rich client - that would be 1 client installation per user. The opportunity for configuration problems and such increases exponentially.
--
David
Hi David,
Thanks for your comment. You're the first writing visitor and I'm pleased to see you here.
Let's touch the redeploy problem first. I believe the need for redeployment have little relation with existence of DTOs in our design. On the client-side we design an interface to our business logic classes. We change the server-side somehow. If we want our client to behave differently we do redeploy. If we won't we keep our client interface untouched.
I completely agree with you regarding caching. Just let me say it in other words. What we really need is to (1) transfer data across the wire and (2) store (cache) received data on the client locally. DTO - Memento is applicable here.
Post a Comment
<< Home