dcsimg
DAO Pattern v/s Generic DAO Approach
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Deepak_Pant
Posted On:   Friday, September 20, 2002 07:14 AM

I need some expert advice in deciding which Data Access strategy is better for my current J2EE project. I have two options in hand: 1) To use generic DAO object. This component will encapsulate JDBC calls and provide common methods like executeSQL(), executeSP() etc. All business components will call this generic DAO to access database. To provide generic interface this component will exchange information using Map or List style objects. Business object will pass the SQL statement of the name of the stored procedure to the DAO for execution. 2) Second option is to follow classic DAO pattern and have almost one DAO behind every business component. Keep DAO interfaces/factory and simi   More>>

I need some expert advice in deciding which Data Access strategy is better for my current J2EE project.




I have two options in hand:




1) To use generic DAO object. This component will encapsulate JDBC calls and provide common methods like executeSQL(), executeSP() etc. All business components will call this generic DAO to access database. To provide generic interface this component will exchange information using Map or List style objects. Business object will pass the SQL statement of the name of the stored procedure to the DAO for execution.




2) Second option is to follow classic DAO pattern and have almost one DAO behind every business component. Keep DAO interfaces/factory and similar stuff. Business objects and DAO can exchange information using specific value objects which I think will perform much better than Map or List type objects. This involves writing lot of DAO classes over just 1 generic DAO component.





Does anyone have any experience w.r.t performance, implementation, flexibility around this?

   <<Less

Re: DAO Pattern v/s Generic DAO Approach

Posted By:   Christopher_Koenigsberg  
Posted On:   Monday, September 23, 2002 07:28 AM

I did a hybrid of both your approaches: first a parent class, the generic DAO, which knows about generally connecting to the db etc., and then subclassed it for a number of specific DAO's, that override and/or extend to know about specific business object stuff.



But with the value objects that you pass between your business objects and your DAO's, you do get into the usual object-relation impedance mismatch problem, when you have some single "objects" that sometimes (but not always) need multiple rows from db relations, and you have to work out which value objects can be single valued, or which have to be Map or List types, and when to fetch minimally vs. greedy/extensively, i.e. when anything is accessed in a business object leading to a value object/DAO that can either bring back single valued info OR dig in to all the multiple rows of sub-objects (from member fields etc.).



So in a situation like this you might get into designing a cacheing strategy (in accessing a Customer address, do you also go and fetch all info up front, about all their Accounts, Orders, etc.? possibly returning loads of data that you don't all need yet? Or fetch none of it up front, leave it all for later if needed, possibly leading to lots more db roundtrips later? Or fetch just some it now, and the rest later, guessing what might be most needed, or what might be most expeditious to fetch in advance and avoid roundtrips, rather than wait for later?). Unless you go ahead and use CMP EJB's to do this for you (we've just been doing our own, so far, with DAO's, no EJB's yet).

About | Sitemap | Contact