• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Should a DAO contain another DAO?

 
Ranch Hand
Posts: 96
Scala VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Samuel Cox
Ranch Hand
Posts: 96
Scala VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Samuel Cox
Ranch Hand
Posts: 96
Scala VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 96
Scala VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How about books?
[ October 24, 2005: Message edited by: Samuel Cox ]
 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic