DAO and DTO

[michael yeung]

I have heared that people build J2EE application using DAO and DTO.
What are DAO and DTO used for?

Thank you!!!

[Nicholas Cheung]

I have heared that people build J2EE application using DAO and DTO.
What are DAO and DTO used for?

Data Access Object (DAO) is a pattern for accessing database. It encapsulates the *flows* for how you access the database. Thus, as a caller, you dont need to know how the DB is connected and access, you just know you are querying data from the DB, in regardless of what DB you are connecting, which driver you are using, etc.

Data Transfer Object (DTO) is an object to hold data objects, which could be transferred across various tiers. It could be some domain objects obtained from database, it could be the result data set from MQ messages, etc.

Nick
[ December 01, 2004: Message edited by: Nicholas Cheung ]

[Sathya Srinivasan]

Originally posted by Nicholas Cheung:

Data Access Object (DAO) is a pattern for accessing database. It encapsulates the *flows* for how you access the database. Thus, as a caller, you dont need to know how the DB is connected and access, you just know you are querying data from the DB, in regardless of what DB you are connecting, which driver you are using, etc.

I guess this can be generalized further. The DAO typically provides the "interface" for the methods you need to access a 'persistance mechanism' (which can be a DB or even a File System) so that the client is shielded from the data access mechanism. Thus, if you decide to change from File System to DB, you won't change the client code.

Originally posted by Nicholas Cheung:

Data Transfer Object (DTO) is an object to hold data objects, which could be transferred across various tiers. It could be some domain objects obtained from database, it could be the result data set from MQ messages, etc.

To add to this, a DAO (or a layer accessing a DAO) may return a DTO.

[Pradeep bhatt]

Hi
More details here
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

[Stan James]

Thanks for the Sun links! If you're not familiar with those J2EE patterns pages they are very good, and a common vocabulary for lots of J2EE developers.

I view DTO as a necessary evil, one of my last choices. I've been working with a vendor framework that uses DAO and DTO generated from Rose models. We can't add behavior to either one. A stateless web server with one pile of objects with no behavior and another pile with only behavior is too much like COBOL, not great OO.

[Corey McGlone]

Originally posted by Stan James:
I view DTO as a necessary evil, one of my last choices...

DAO, on the other hand, is practically essential when dealing with a data tier in an application. You never want your database/file system logic to be mixed in with your business logic.

[Pj Murray]

Hello Michael,

You could take a look at the link below for some additional information on DAOs.

http://www.codefutures.com/products/firestorm/benefits/


The best way to learn is really just to try out DAOs in a simple application.


PJ Murray
CodeFutures
http://www.codefutures.com

[Scott Ambler]

You might find Encapsulating Database Access to be of interest. It compares and contrasts several options.

- Scott

[Ilja Preuss]

Originally posted by Stan James:
I view DTO as a necessary evil, one of my last choices.

Martin Fowler has some interesting comments on the pattern: http://martinfowler.com/bliki/LocalDTO.html

[Guy Allard]

Originally posted by Scott Ambler:
You might find Encapsulating Database Access to be of interest. It compares and contrasts several options.

- Scott

Nice site. Thx, Guy

[Bruno Collet]

Hi,
I do not think that DTO are a necessary evil. Some argue that they are not even OO, but I disagree with that.
The 3 paradigms of OO are encapsulation, inheritance and polymorphism. Saying that a DTO is not OO because it does not encapsulate behavior is like saying that a type is not OO because it does not inherit from another type.
DTO is a useful pattern, and is mandatory for SOA systems. I have had a lot of frustration working with DTO, both coarse and fine grained, but I finally settled on what I call "custom-grained DTO". In particular, I have found that the performance consideration underlying coarse-grained DTO to be simply a bad idea. For those interested I explain my thoughts about this in http://www.practicalsoftwarearchitect.com/articles/customgrained/customgrained.html

[Stan James]

It's interesting you said "not a necessary evil" but then "mandatory". Must have been the "evil" you objected to, not the "necessary". I think we agree that in certain architectures you just gotta have em.

What is "good" is probably whatever you can live with over the long haul of the application or component - productivity, maintainability, robustness to change, motherhood, apple pie, etc. With care you can use DTO where necessary and have all those good things, so "evil" is definitely an exaggeration with a wry wink intended. I wound up backing off to "not great" later in the paragraph.

I like Tell, Don't Ask as a goal. The better an object hides its data the better. An object that is only data does poorly on this scale. Of course that's not the only scale of goodness so we might not mind too much if we can isolate the potential for mischief.

[Bruno Collet]

Yes you are right Stan, I objected about DTO being "evil", not about them being "necessary".
I think that the "tell, don't ask" approach works well for domain objects (i.e. business objects, BO), but not for inter-component communication. I do not see how a system made of multiple components and complying with SOA basic rules, can work without using DTO.
But I suppose that the discussion is getting off topic...
And YES I saw the "apple pie" in your post, proof that I read it thoroughly

[Stan James]

So I think we're both at calling them necessary and less than ideal. I can live with necessary when I have to, but it might make me step back and ask what makes them necessary. A distributed, poly-platform SOA would seem to be a pretty solid reason for DTOs. Some casual (and reversible) layering decision within my server might not be.

[Ilja Preuss]

Originally posted by Bruno Collet:
I do not see how a system made of multiple components and complying with SOA basic rules, can work without using DTO.

What are those SOA basic rules, and why would we want to comply with them?

[Bruno Collet]

Hi Ilja,
Sorry for this late post - holiday time
You can find the answers to both of your questions in documents that can be downloaded from:
http://www.middlewareresearch.com/soa-blueprints/