• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Structure for Data Access Object(s)

 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks.
 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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

Regards,

Nikhil
 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Corey,

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
 
Nikhil Vasaikar
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Nikhil
[ November 05, 2004: Message edited by: Nikhil Vasaikar ]
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Corey,

Have you read this?

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Also -- you might also want to put some facade or helper classes between the DAO and your client to provide coarser-grained data objects.
 
They worship nothing. They say it's because nothing lasts forever. Like this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic