Should a DAO contain another DAO?

[Samuel Cox]

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

class BusObj {
BusObj2 busObjChild;
}

Is it considered bad design to do this:

class BusObjDAO {
public BusObj getBusObj(long id) {
BusObj busObj = new BusObj();
//establish connection
BusObj2DAO busObj2DAO = new BusObj2DAO();
BusObj2 busObj2 = BusObj2DAO.getBusObj2(id, connection);
return busObj;
}
}
  

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]

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]

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]

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]

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]

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]

How about books?
[ October 24, 2005: Message edited by: Samuel Cox ]

[Scott Selikoff]

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]

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.