Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is ORM and DAO are substitute or complementary to wach other

 
amit sharma
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I confused over whether orm and dao is complementary to each other or substitute to each other .We can made DAL layer and implement that layer using orm .DAO provides very clean separation .Without DAO business logic has the responsibility for persisting objects .Even we use orm it still not provide very good separation between business layer and persistent layer.
Thanks
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
DAO and ORM are not synonymous. Good practice would have an ORM layer accessed through a DAO layer, since the ORM layer itself is a data access implementation (in the same way as JDBC is for example).
 
Tim Holloway
Saloon Keeper
Posts: 18367
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An industrial-grade webapp almost certainly should have distinct DAO and persistency (ORM) layers. For one thing, if you design the ORM access via interfaces, you will then be able to switch in a mock persistence layer for testing purposes without impacting the business logic or the DAO services.

This is especially true if you're using Spring to inject things, since then you won't actually have to change the application code to test it - just swap in a mock-ORM Spring configuration.
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As Paul said, DAO and ORM are not synonymous. There really are much different forces that push us to use a DAO pattern, including transparency, portability, and vendor specialization.


*Components such as bean-managed entity beans, session beans, servlets, and other objects like helpers for JSP pages need to retrieve and store information.
*Persistent storage APIs vary depending on the product vendor.
*Components typically use proprietary APIs to access external and/or legacy systems to retrieve and store data.
*Portability of the components is directly affected when specific access mechanisms and APIs are included in the components.
*Components need to be transparent.


The Core Patterns Page has some great information on the ins and outs of the Data Access Object pattern:

Core J2EE Design Patterns from Sun: Data Access Object

-Cameron McKenzie
[ September 07, 2008: Message edited by: Cameron Wallace McKenzie ]
 
Pj Murray
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may find this blog by Andy Grove on DAO versus ORM interesting:

http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic