This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Object Relational Mapping and the fly likes To Chris Richardson: Eliminating DTOs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "To Chris Richardson: Eliminating DTOs" Watch "To Chris Richardson: Eliminating DTOs" New topic

To Chris Richardson: Eliminating DTOs

Scott Johnson
Ranch Hand

Joined: Aug 24, 2005
Posts: 518

Your book has a section on "Eliminating DTOs". Why should Data Transfer Objects be avoided? What pattern should replace them?

In the application my team is currently developing, we've made extensive use of DTOs and the Transfer Object Assembler pattern. These patterns have allowed us to reduce the number of calls to EJBs and decouple the client from the complexity of the data model.

Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703

As another Scott whose used DTO's as well, how do you transfer data without exposing the backend without using DTO's? I'm curious too, since DTO's have many positive features.
[ January 24, 2006: Message edited by: Scott Selikoff ]

My Blog: Down Home Country Coding with Scott Selikoff
Chris Richardson
Ranch Hand

Joined: Jan 10, 2006
Posts: 50
Scott & Scott,

ORM frameworks such as Hibernate, JDO and EJB 3 support what are called detached objects. These are previously persistent objects that are "disconnected/detached" from the database and returned by the business tier back to the presentation tier.

Returning the detached objects eliminates the need to instantiate the DTOs that mirror the domain objects. For example, rather than instantiating AccountDTO and copying data into it from Account, the business tier simply returns the Account. In my experience this works well. It cuts down on the "boring" domain DTO and DTO assembler code.

But sometimes there is a concern about exposing too much of the domain model to presentation tier. One solution for a domain object to implement a "view" interface, which defines the API it exposes to the presentation tier. For example, Account could implement AccountView interface, which exposes getters such as getBalance() and hides Account.debit() and Another option is to return adapters that delegate to the real domain object. This requires most code but less than having DTOs.

Of course, whether DTO-free approach works for your application depends on your particular requirements.


Enterprise Java consulting and training - <a href="" target="_blank" rel="nofollow"></a> Author, POJOs in Action - <a href="" target="_blank" rel="nofollow"></a> Enterprise POJOs blog - <a href="" target="_blank" rel="nofollow"></a>
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703

Where I've seen DTO's having the most use over detached data source BOs is when data types are involved. For example, the user may enter the date/time separately on JSP page that gets converted to a DTO, but the database might store these two separate fields as one. There's other such examples such as when you want the client to sent raw/uncoverted data, that the application tier should convert/process before saving as a BO.

I guess where I see it becoming difficult is when DTOs map to multiple BOs and/or DTO's map multiple fields to single fields in BOs. Even with defining an API, managing the conversion between views and bos could be difficult.

Although I have seen a number of cases where the DTO's and BO's were virtually identical, so its not always this difficult to weed DTO's out. I suppose I still object to getting rid of them all together for EJB service or web service type applications since it exposes backend structures I'd prefer to abstract away from the user.
Scott Johnson
Ranch Hand

Joined: Aug 24, 2005
Posts: 518
In the application I mentioned above, I have some issues similar to what Scott mentions.

There are datatype differences between the client and the data model. My Assembler object is filtering some of the collection data before populating the DTOs. The fields in the DTO reflect the client code's requirements and do not map nicely to the data model.

The DTO and Assembler pattern have allowed me to decouple the client from the data model, but the cost is a lot of "boring" code.

Your suggestion about the view interface is very interesting. I think I can use this concept to refactor and simplify some of my objects.

Thank you very much for the response.
I agree. Here's the link:
subject: To Chris Richardson: Eliminating DTOs
Similar Threads
Implementing Patterns
Retired Patterns
Is including Mutable Objects in VO/DTO pattern a violation of OO Programming ?
Passing value to EJB from Servelet
Hardcoding vs. Flexibility