This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

DAO and DTO

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have heared that people build J2EE application using DAO and DTO.
What are DAO and DTO used for?

Thank you!!!
 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
author
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You might find Encapsulating Database Access to be of interest. It compares and contrasts several options.

- Scott
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 776
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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/
 
Won't you please? Please won't you be my neighbor? - Fred Rogers. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!