Sounds quite cool :)
Unfortunately, I already lost the argument at work to use iBatis instead
of Hibernate. Hibernate isn't bad, but I would have preferred iBatis.
Oh well.
Frank
Larry Meadors wrote:
Actually, the iBATIS DAO stuff works well with darn near any data
access technology - sqlmaps, hibernate, jdbc, and about 5-6 more
"out-of-the-box", so don't think that using the iBATIS DAO means you
have to use iBATIS SQL Maps - they are very seperate tools.
What it does is similar to what you are describing - it creates a Map
of DAO implementations that are keyed by the interfaces for them. One
assumption that it does make is that the DAO implementations are
thread-safe. It will also allow you to use the implementation as the
key, but IMO this is not the best practice.
Anyway, you can define an AccountDao interface with the basic CRUD
operations, then implement that interface using any data access
technology you prefer. Then you use the iBATIS DaoManager to get
(shared) instances of those DAO classes.
It will also help manage transactions, too.
Larry
On 9/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
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]
--
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]
