Hi,
my suggestion would be to have a closer look at the
Spring framework. IoC / dependency injection is
really cool once you get a grasp of it. Instead of
having the service look up a DAO instance, you
simply inject the fitting implementation class into
the service via Spring. The service itself only knows
the DAO interface and has a setter property for it.
Note that this way you also have to deal with
shared instances (like with iBATIS DAO) and
therefore have to keep heed of thread issues, but
luckily Spring also provides template implementations
for most common database access solutions (JDBC,
iBATIS, Hibernate, JDO, Toplink (by Oracle) which
are said (I still have to check that out) to be
inherently thread-safe. Btw. can anybody here
confirm this? Currently, we are probably too
cautious in this direction (using iBATIS).
-- Chris.
----- Original Message -----
From: "Paul Benedict" <[EMAIL PROTECTED]>
To: <user@struts.apache.org>
Sent: Thursday, September 01, 2005 6:19 AM
Subject: DAOs in service methods
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?
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
