Java Data Access Object Design (DAO)

[Ed Thompson]

I am designing a small in-house webapp (Tomcat) that accesses 6-10
database tables. I am trying to determine from a design perspective if
I should have a single DAO that encapsulates ALL database access for the
app, or multiple (~6) DAO's to access various poritons of the model.

I looked at the Java Design pattern article and did not get a clear
direction. Part of the question I guess is related to scope - should
I keep a DAOP around for a while (session scope) or let it expire
quickly knoiwing I wmight need it again (request scope).

Does this question make sense?

 

[VisionSet]

I am designing a small in-house webapp (Tomcat) that accesses 6-10
database tables. I am trying to determine from a design perspective if
I should have a single DAO that encapsulates ALL database access for the
app, or multiple (~6) DAO's to access various poritons of the model.

I looked at the Java Design pattern article and did not get a clear
direction. Part of the question I guess is related to scope - should
I keep a DAOP around for a while (session scope) or let it expire
quickly knoiwing I wmight need it again (request scope).

I definitely wouldn't put it in session scope, very wasteful.
Shouldn't be any need to have it in request scope either, If your
application is complex enough to warrant 3 full tiers (Model,View
Controller) then the model should handle all the data access. Are you
suggesting that your view will be manipulating persistence?

I have rolled my own DAO's and have strictly one DAO for each table. All
subclass from an Abstract data source.
Usual chain of events for my System is:
Instantiate relevent DAO's, decorator pattern style for joining tables.
DAO's are responsible for all select statements, which delegate to an SQL
(or whatever) builder class. This tracks their position in the select for
future retrieval by column index. Each DAO have some stock methods for
getCustomer or lists of, but custom queries can be built external to the DAO
and passed in.
DAO then executes query calling on superclass methods to facilitate, and
returns a relevent value object, or list of.
DAO can be reused, for other queries.
Then I have the values objects and DAO's can be GC'd
Model layer then usually returns to Controller.

I too initially looked at the enterprise pattern I think you are refering
to, I based mine on that, I don't have the interface, but could add it if I
use other methods of persistence. The main difference is mine uses the
DAO's to help build queries rather than giving them sole responsibility,
this has forced them to be less static than the J2ee DAO pattern.

 

[brougham3]

I am trying to determine from a design perspective if
I should have a single DAO that encapsulates ALL database access for the
app, or multiple (~6) DAO's to access various poritons of the model.

I'd lean toward one DAO per logical view of the data. Depending on how your
data is normalized (or not), you might end up with some 1-to-1 mappings
between DAOs and tables and other cases one DAO maps to several tables.

The whole idea is to provide a layer of separation between your app and how
its data is persisted. If you do a strict mapping of one DAO per table, and
then the database is normalized differently and a table is added, you'll
either be in the situation of having an exception to your mapping scheme or
you'll need to change your code that accesses the DAOs...and that's what
you're trying to avoid.