This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Let me try to explain the design I currently have and I'll see if anyone can spot anything I can do to improve it. My goal is to make a simple, easy to use abstraction layer for database access. I want the various business logic classes to be able to invoke meaningful methods in the abstraction layer and have the abstraction layer take care of the details of database connections/SQL/etc. Classic problem, right?
My first step was to make a class that would perform the database access. I gave it various methods, such as addAddress, updateAddress, etc. This works great from the business logic side - it simply does a call that looks like this:
In some cases, a single method might take 10+ parameters (such as adding a new address). In order to facilitate this and to make my methods reusable, I made such methods take an interface, such as an AddressInfo interface, that looks something like this:
So, the business logic code can create a new object (any object) that implements that inerface and hand it to the DAO for execution.
All of that I'm fairly happy with (although if there are improvements that can be made, I'm listening). My problem is with the DAO class, itself. This is a fairly hefty app with a lot of database access work. For every different type of access required, I'd need an additonal method in my DAO class. The result would likely be a monolithic database access class. I'd like to avoid that, if possible.
My thought was to break the various database functions out into groups - address functions (add/insert/update/delete/etc.) in one group, contact functions (add/insert/update/delete/etc.) in another, and so on. Each group could then go into it's own DAO class, such as AddressDAO and ContactDAO. Some of the common pieces, such as opening connections, could be easily abstracted into a parent DAO class.
This does a nice job of breaking apart the DAO class into smaller, functional pieces, but now I've got a new "problem." The business logic classes now need to be aware of a handful of DAO classes, rather than just one. I'd prefer if the business logic didn't have to make a decision about which DAO to utilize.
One plan would be to use that parent DAO class as a "decision maker" class. Not only could I generalize some things into that class (such as acquiring a database connection), but I could include methods like addAddress or updateContact in that class. Those methods would probably look like this:
Even though these methods would be remarkably simple, I'd still end up with a giant class, which is what I wanted to avoid in the first place. :roll:
Is there some other way I can do this that I'm not seeing? Right now, my two options seem to be to require the business logic classes to be aware of the structure of the DAO classes (that might be about 5-6 DAO classes) or have a giant, rather "dumb" DAO class that does nothing but invoke the methods of the other DAO classes.
I feel that you can have seperate DAO for customer,address and also a DAOFactory.
This DAO Factory should look up which DAO to invoke based on a key.
You may implement a common interface for all the DAOs, so that your factory would return the interface.
e.g. CustomerDAO implements CommonDAO AddressDAO implements CommonDAO
Inside the factory you can have code something like the following CommonDAO daoObj = DAOFactory.getDAO(key)
Ur DAO.properties may look like the following: customer = com.xxx.dao.CustomerDAO address = com.xxx.dao.AddressDAO
Hope it helps Regards
SCJP,SCWCD,SCBCD,SCEA Part I
Joined: Aug 18, 2004
I suggest, you may also make the DAO class more general by using a DAO interafce that is implemented by the actual DAOs
All your client knows is the DAO class all the DAO class knows is the AbstractDAO interface. The client does not need to choose between the DAO objects. This way changing the code as per the growing requirement would be easy- the design for change approach. This is what I could think of now. Hope this helps.