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.
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 ]
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.
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.
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.
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.