DTO's are useful when implementing a Unit of Work pattern; this can be applied to any application, distributed or non-distributed, web or non-web.

I just start a Unit of Work when the servlet starts executing with a servlet filter (or an interceptor in WebWork or whatever). That way I can talk directly to the domain objects and do clever lazy loading and all that without having to introduce costly and bulky DTOs.

The biggest problem with this approach is that it might hold on to a transaction in the database for too long (most importantly the locks associated with that transaction). This is solvable of course and doesn't require you to resort down to full on DTOs. Remember that premature optimization is the root of all evil!

One way of solving this problem might be to delay the actual allocation of a database connection to the unit of work until it is really needed. Another is to disable the unit of work-per-servlet model for a specific servlet that is causing a problem.

Some people design according to the trickiest corner cases. This is not a very effective design strategy. I design according to the 95% case and then have a different design for the last 5%.

Martin Fowler has had a couple of words to say in the past about this himself:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

Hi, I can’t fully agree with you here.
I think DTO are very useful within web applications. They often act like Data containers within the application, and if you need to distribute any of them you already have them implemented. But I do not implement then in the way Fowler explain the DTO.
In my solutions I use my entities or value objects as DTO. They aren't really smart objects. Often they contain attributes and attributes only. I don't build my DTO as fowler does here. http://www.martinfowler.com/eaaCatalog/dtoSketch.gif

I use my entities for the DT. And I only use DTO if I need too.

I think you have seen applications made by developers that can't see the aggregate relations between a database and DDD. And made big ugly objects instead of small entities? Or do you really see this pattern, where people use small entities and bind them into a big one and then use this big one within the application as their aggregates?

What’s your thought about this?

Best,
Johan

AAA... Now I see your point. I think I'm one of the developers you don't like :-)

I use Entities with attributes only, I do not add business rules to them. If I have one Invoice Aggregate root, I only use this to fill it with data for other object to handle them. I do not have methods like Save, GetTotal etc in this class. For me an invoice class is like a blank invoice paper. And a Paper do not have any functionality, something else is handling this paper. I think that's model is a more real life look a like. I can't see how an paper can be smart.

Or am I wrong here too?

Best,
Johan

Yes, you would be one of those developers that I don't like. ;-)

That said, I think your approach is much better than many apps I've seen. In these apps there would be domain objects that had very limited functionality (ie. Anemic Domain Model) and then there would *also* be DTOs for each domain object. And if that wasn't enough there would also be masses of code to copy data in and out of all these objects. Following a pattern like that is guarantueed to make a small and trivial app seem huge and complicated!

Johan, I would advise you to read Domain Driven Design: http://domaindrivendesign.org/
In this design an Invoice is supposed to embody the knowledge that a system has about an invoice. Be it rules on how to process it, whether it's late or not, how to pay it, how much to pay and so on. Simpler systems to not require a domain driven design, but really complicated systems can easily become unmaintainable without something like this.

Hi...

I think I used my Entities like value objects but with identifiers. I have read the DDD book, but after reading some posts and articles written by Fowler and Evens I consider the DDD book didn't handle this topic very well.

I have now added a post at my blog about this.

Pleas add feedback to this post.
http://www.nsquared2.net/johan/viewpost.aspx?PostID=115&showfeedback=true

Note:
In my latest DM I used Entities and value objects, Repositories and O/R Mappers for the persistence.
But still had some problems where to put all my business rules.

Best,
Johan

IMHO, DTO is close to top of the list of one of the most abused patterns (right behind singleton and factory). The fact that Sun included it in the DAO pattern is yet another abuse of the pattern. I have not see the need to substitute plain old java objects with this abstraction of an object.
One really needs to ask, what was the motivation for this pattern? For DTO is was to move data from an environment in which the containing object lived to another where it could not. I.E. moving the data in an entity bean to another location.

This is not to say that there are no other uses for the pattern but using it for lazy loading (see value object or proxy) would not seem to be one of them. Using them in a non distributed environment seems dubious at best. The down side of DTOs is that the often seperate data from the Object that is responsible for maintaining it's state. It also creates situations where layers loose ownership of key elements and become horribly coupled to outer layers. The things don't tend to happen when the pattern is not abused (or used inappropratly).

Cheers - Kirk

This could be a touchy subject, and to a very large degree I have to agree with you. I personally do not have specific DTOs, but I do admit to having anemic domain models. I did find over time that they were often more trouble than they were worth and that sometimes it best to not use a full model when you don't really need one. A good, but somewhat flawed, example is the FastLaneReader pattern which just grabs some data and displays it. Who needs an object for simple tabular data?

On the other hand sometimes the data is easier to display via objects. Graphs and trees come to mind here. One area that I recently have gotten into is services. WHere I work we have serveral common services such as employee and customer information, that are shared across many applications. Even having dummy objects here helps as each application doesn't need to know anything about the underlying database and we don't have to replicate all of the persistence information for each application. We just deploy the service and each application has a simple jar file with a simple bean that encapsulates the access of that particular service. Under the covers the service is using web services and EJB SSBs, but the client only sees a simple java class 'client' and the resulting data objects of course.

I think a lot of the dummy object phenomenon going on right now is the love of O/R tools like Hibernate, JDO and EJB-CMPs. They force the developer into using nothing but an object model. It is one of the reasons I built my own (and pitched to Bob McWhirter a couple of days ago) persistence tool, so that a developer can use objects if the want, or not if they don't.

Is the model object in an MVC framework considered as a DTO also? If yes, will that mean the MVC is propagating bad OO design?

Are bean classes considered as DTO?

The blog would have been a productive reference if the author provided some better alternatives than using DTOs. A lot of developers will definitely benefit from it.

Code uncovered by tests ? Kill it ! (Guantanamo)
Bad applied pattern ? Kill it ! (DTO)
Bad architects or programmers ? ooops..

He, he ! May be you guys are working too much...

DTOs have a purpose and if they are being created just for the sake of being created, why? I think that is the point being made by the post and I agree this is a waste.

Some of the post's replies, however, seem to talk about a different animal. For instance, Jojo asks to provide better alternatives than using DTOs. I assume he means alternatives to representing data in your system and not alternatives to a mechanism of transferring data in a distributed manner. DTOs have a distinct purpose which is not representing data in your system. There are a couple patterns that can be used to do this instead: VO/DAO (and variations), disconnected recordsets, others?

I personally like the disconnected recordset paradigm which is in the forefront in ADO.NET, but I'm not aware of any non-proprietary implemenations in Java, but auto-generated VO/DAOs are nice too.

IMO Entity EJBs should not be used to model data. If they are used at all, they should only be used to maintain concurrency which could encompass different data types and/or multiple instances of a data type, so it should be used in conjunction with the VOs.

*Occasionally*, secondary objects (lets not call them DTO's) are useful for providing a simplified view to the presentation (templating) layer.

Lets say, I am using WW. Rather than have really long WW expressions to navigage your real domain:

(iterate over collection of foo's)
/foo/bar/moo/cow/pippy/longstocking/pol/pot/name
/foo/bar/moo/cow/pippy/longstocking/pol/pot/age
/foo/bar/moo/cow/pippy/longstocking/quantity

You may want to simplify the WW expressions (and hence make them far less fragile!) by passing a collection of BlahViewObject's which contain the raw data required by the view. (name, age, quantity)

Now, if you compare these objects to DTO's, you might find a striking similarity in purpose (aggregation of data for the view).

It must be said, though, that these occasions shouldnt arise that frequently.

-Nick

Nick,

I agree. Simplifying the access to the domain is a key responsibility of the Application Layer (by using terminology from Domain-Driven Design).

Your suggestion is to do this by 1) creating a new "view" object that represents this new simplified view and 2) writing code somewhere else that fetches this information from the domain and puts it in the "view" object, the "view" object acting as a stupid data holder.

My suggestion, is to put both this functionality in the same object. This is responsibility driven design: the "view" objects responsibility is to present a simplified view of the domain.

Generally speaking; whenever you encounter an object that is a stupid data holder which other objects put data into and extract data from, then you haven't found the true responsibility for that object. Usually you will found a few isolated places that actually put data into the object (or less common, extract data from it) isolate this functionality and merge it into the "stupid" data holder.

Voila! You now no longer have a "stupid" data holder and a bunch of procedural code, you now have a real living object with true responsibility.

The best way to collect data from a database is to use a Stored Procedure, which can be easily optimized and completely mask the database complexity to client software, using objects to map each DB table is a dogmatic approach which is just a waste of time.

Well, applications come and go but databases are stay. Their data is much more valuable than application which put it.
With popularity of OR Mappers it is much easier to have mapping and generate database schema and objects than maintain them separately. It is pretty easy to design database schema from UML class diagram.
The best minds in Java Land couldn't agree even on Domain model for Web Applications, in Python land there are more web frameworks than comments in the code.
What can be said about something more complicated?

>> isolate this functionality and merge it into
>> the "stupid" data holder

Fair point.

DTOs can be ugly but I think they're a necessary evil when building web applications using entity beans. If your architecture includes a Service Layer in the form of Session Beans, do you really want to expose the entity beans to clients of the Service Layer?

If any of your entity beans have methods with a "required" transaction attribute, clients of the Service Layer could start a transaction. Obviously, that's not ideal.

Of course, the real culprit here is not the DTOs in my opinion - it's the entity beans. Entity beans have fostered the creation of all kinds of smelly code over the past few years.

I agree with your comments on DTOs when the domain model is implemented with POJOs.

What do you think about DTOs when the domain model must be exported as web services to thick clients?

Juan,

In this case there is obviously a distribution boundary in play so a DTO is in order. Do explore the option of just data binding your domain objects though, most data binders are pretty good at tuning the XML that comes in and out of web services so you can skip an intermediary object layer and just use your domain.

a bean is a great way to either
a) easily get trigger happy and make a simple app a nightmare on DTO street or (not to be confused with XOR)
b) a way to make those "programmers" that cant adhere to some kind of standard (lets agree on something that is not related to cafe for once folks) follow a chewable rdy to swallow standard...
Ok, im gonna make up a 'standard'...guaaaaranted that in no more than 24 hours after i posted on a blog with a decent amount of 'followers' there will be at leat n*n-1 permutations...
I can only gather that coming up with patterns, as noble as the cause might be, will only cause more confusion...
.
.
.
But obviously there is no other option.......can we get to the model without going through the controller for once???.....:)

Application should use DTO regardless of types of application. i.e. web-nonweb or ditributed ot non-distribute.
DTOs should use for the followings:
• Reducing network overhead.
• "It's an accepted practice in the industry to let your DTO mirror your entity bean"
• You can do a lot of cool things with DTOs. Aside from simply sending them over the wire, you can use a DTO factory and reflection on the client side to selectively pick out the desired attributes from an entity's DTO. The entity bean 'stuffs' its DTO with its corresponding values and sends it to the client; however, if the client only wants a subset of these values it can create another DTO (using a custom DTO factory class) that take only the selected values from the entity bean DTO. It does this using reflection. .

wmunifjp gjiuvvwf http://dkdtembm.com hnuswkak qicadukh [URL=http://oegzdmox.com]kuvxcppx[/URL]

ppuoxydf http://jjwtrqid.com koqduqbc thgzhcdi fdpctjlo [URL=http://ntdsggnd.com]mykeiwja[/URL]

qpfupiyt jshfrtwf http://scxpjopw.com oogeblyo wvnxsxwr [URL=http://sbctpjdt.com]xzxnqynn[/URL]

The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

When we ask for advice, we are usually looking for an accomplice.

An honest politician is one who, when he is bought, will stay bought.

Happiness lies in the joy of achievement and the thrill of creative effort.

It had only one fault. It was kind of lousy.

Is there life before death?

hi