Win a copy of Head First Android this week in the Android 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

How to write a simple generic DAO class?

 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How to write a simple generic DAO class to use a single datasource, thus without fancy things like Hybernate, JTA etc.

With the same class i want to retrieve/store single objects but also objects with a parent/child relationship.

My question is what is best practice if you want to hide all the data access logic from the business logic including transactions.

for example if you want to store an Order Header you could write something like this

DAO.storeOrderHeader(){

starttransaction
storeOrderHeader
commit

}

DAO.storeOrderLine(){

starttransaction
storeOrderLine
commit

}

client:
DAO.storeOrderHeader()
DAO.storeOrderLine()


The problem with this code is that storing a complete order should be one transaction:

client:
starttransaction
DAO.storeOrderHeader()
DAO.storeOrderLine()
commit

But now you haven't hide all the implementation details of the DAO layer.

So how do you solve this?
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, you haven't exposed any implementation details, because transaction demarcation shouldn't be the responsibility of the DAO.
DAO's are meant to participate in transactions, not initiate of commit them.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jelle Klap wrote:Actually, you haven't exposed any implementation details, because transaction demarcation shouldn't be the responsibility of the DAO.
DAO's are meant to participate in transactions, not initiate of commit them.



But in the case of JDBC to demarcate the transaction you need the connection object and isn't that part of the implementation?
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, the JDBC-based DAO ultimately needs a Connection - as a dependecy.
However, the logic and responsibility of obtaining a Connection shouldn't be part of the DAO implementation - think dependecy injection.
If you decouple the Connection and DAO in this manner, transaction demarcation outside of the DAO becomes a possibility.
You could take a look a Spring's (JDBC) DAOSupport and Template classes to get an impression of how this al ties together.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic