Forums Register Login

Should a DAO contain another DAO?

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
How about books?
[ October 24, 2005: Message edited by: Samuel Cox ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
A sonic boom would certainly ruin a giant souffle. But this tiny ad would protect it:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 4034 times.
Similar Threads
Structure for Data Access Object(s)
URGENT!!
how to populate a form from database ?
loading a class via reflection without knowing the full qualified path ?
Struts..
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 19:47:38.