wood burning stoves
The moose likes OO, Patterns, UML and Refactoring and the fly likes Structure for Data Access Object(s) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Structure for Data Access Object(s)" Watch "Structure for Data Access Object(s)" New topic

Structure for Data Access Object(s)

Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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.

Any comments are appreciated.


SCJP Tipline, etc.
Nikhil Vasaikar
Ranch Hand

Joined: Aug 18, 2004
Posts: 56

I am not sure, however I think you might want to use the Bridge Pattern


Sujatha Kumar
Ranch Hand

Joined: Jan 05, 2004
Posts: 134
Hi Corey,

I feel that you can have seperate DAO for customer,address and also a

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

Nikhil Vasaikar
Ranch Hand

Joined: Aug 18, 2004
Posts: 56
Hi Corey,

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.

[ November 05, 2004: Message edited by: Nikhil Vasaikar ]
Robert Hayes
Ranch Hand

Joined: Oct 24, 2004
Posts: 116
Hi Corey,

Have you read this?


Also -- you might also want to put some facade or helper classes between the DAO and your client to provide coarser-grained data objects.
I agree. Here's the link: http://aspose.com/file-tools
subject: Structure for Data Access Object(s)
It's not a secret anymore!