aspose file tools*
The moose likes JDBC and the fly likes Should a DAO contain another DAO? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Should a DAO contain another DAO?" Watch "Should a DAO contain another DAO?" New topic
Author

Should a DAO contain another DAO?

Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Let's say I have a business object with the following structure:



Is it considered bad design to do this:



or should I have some kind of transaction class handling the composition of the 2 DAO into the one business model object (ie http://javaboutique.internet.com/tutorials/dao/)? If I do it the above way, it would appear that I have to load the entire object every time I want a BusObj; however, I would only like to get certain pieces as they are necessary.

Any tips or pointers to resources that would help me in this endeavor are greatly appreciated.
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30966
    
158

Samuel,
If I do it the above way, it would appear that I have to load the entire object every time I want a BusObj;

I think this answers your question. This code smell is telling you that the method is doing too much.

If you have someone updating the database, you do need a transaction. This is the case with your example too. The database doesn't know that the DAOs are nested.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Thanks for the reply.

Your comment makes me think that I should have a DAO for each table, and each DAO be created by some kind of manager who is responsible for transactions. Furthermore, a DAO should have no notion of other DAOs. Would this be accurate?

If this is the case and the business model wants to create BusObj, what should it call? Right now, I have a BusObjDAO factory that creates a connection from JNDI, which gives my model a DAO, which in turn gives the model a BusObj. Should the factory give my model some kind of TransactionManager, which can create a BusObj?

Do you have any links or books that you would suggest that would lead me towards a extendable, maintainable persistance layer design? That link that I gave is the one resource that I have found that discusses a layer between DAOs and some client (the business model in my case).

Thanks.
[ October 20, 2005: Message edited by: Samuel Cox ]
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30966
    
158

Samuel,
You should definitely have a amanger that does transactions. That way the DAO does data access and you can use it with different transaction structures.

I wouldn't always say that there should be one DAO per table. That is a good general rule of thumb. The exception is when having two tables is more of an implementation detail. For example, you have a table with a list of people and another table with parent/child relationships. To get a business object with a child and the names of his/her parents is a valid business scenario. Maybe it would be more accurate to say one DAO per business object.

I can't think of any good websites at the moment.
Sravan Kumar
Ranch Hand

Joined: Sep 11, 2005
Posts: 121
It is ideal to have a DAO for every table, provided there are no complexities involved. If you want to query two or more tables for the same functionality, you can put them in a separate DAO (say, call it serviceDAO). This can be called from the business layer.

Having a DAO per business object is fine because it will ultimately boil down to having one per table if you have modularised them properly.


keep smilin :: sravan<br /><a href="http://sravanpens.blogspot.com" target="_blank" rel="nofollow">I scribble here</a>
Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Thanks for the tips.

I'm glad I didn't go too far in coding nested DAOs I'll construct my business object in a layer between the business domain and the DAOs.
Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

How about books?
[ October 24, 2005: Message edited by: Samuel Cox ]
Scott Selikoff
author
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3716
    
    5

Maybe my notion of a DAO is a little warped from practice, but a DAO per database table seems very excessive.

Some database systems will have hundreds of tables with hundreds of relationships between them, and while it may be easy to manage hundreds of Data/Business Objects (assuming you have an intelligent auto-generation tool) I wouldn't recommend also having hundreds of DAOs.

I prefer to define a DAO per groupings of data. For example, there might be a customer information DAO which is the primary control for business objects such as customer_address, customer_phone_numbers, customer_email and customer_names tables for example. This data would commonly be accessed together, so better to have a single DAO grouping/querying the business objects.

DAOs can call other DAOs, but depending on the scope, it's probably better to move the logic of that up a level to the application service. For example, have an application service call two separate DAOs that don't interact directly but where the application service passes information between them. This significantly improves reusability and encapsulation. Finally, there are some performance exceptions where a DAO might want to call another DAO, although if the DAOs are really so intertwined that it happens all the time, I would probably merge them into a single DAO or use a stored procedure.


My Blog: Down Home Country Coding with Scott Selikoff
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30966
    
158

Samuel,
I think the reason people are having trouble coming up with books, is that JDBC books don't tend to cover this. They are lower level. And database design tends to be higher level. Maybe a book on J2EE design? Of course that would only have a piece about DAOs.
 
 
subject: Should a DAO contain another DAO?