As Leon said, there probably isn't any one "right" answer, although I
think it's fair to say that best practices is as Leon says, to *not*
create a DAO per service method.
What I tend to do, and I'm not claiming this is any more right than
anything else, is to have a DAO factory where I get my DAOs from. It is
the factory's responsibility to get a database connection from the pool
and hand it off to the DAO. In this way I can have a single factory and
get multiple DAOs from it, each sharing the same database connection.
The factory I instantiate for each request, so if I use 10 DAOs during a
single request, it's still only a single database connection.
Using something like iBatis or Hibernate would in effect take the place
of the factory and should deal with these concerns for you, but I have
not yet used either product in a production app, I've always done it
myself (getting away from that!).
Frank
Leon Rosenberg wrote:
On Wed, 2005-08-31 at 21:19 -0700, Paul Benedict wrote:
Hey guys.
I have alot of service objects called from Struts, and
each have a good deal of service methods. Service
methods mainly do business logic and talk to DAO
objects.
Question:
I've taken the approach of service methods having the
responsibility of instantiating DAO objects locally
and using them. Is this correct? Or should I
instantiate all the DAO objects that could ever be
needed in my service constructor, and use them as
instance variables?
Or is there a better design?
Hi,
design is always the matter of the desired functionality, so it's hard
to say what is best for you without knowing your business goals.
But what can be said for sure, is, that instantiating DAOs locally on
each call is a waste of ressources, since each new DAO will probably
create a new connection to the db.
Having one instance per "service" is generelly better, but you must keep
an eye on synchronization and concurrency.
regards
Leon
Thanks!
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]