You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Paul Benedict <pa...@yahoo.com> on 2005/09/01 06:19:35 UTC
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!
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by Larry Meadors <la...@gmail.com>.
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 <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by Leon Rosenberg <st...@anotheria.net>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Christian Bollmeyer on 01/09/05 18:19, wrote:
>
> 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).
I am just catching up on these old mails, and I totally agree that
Spring lends major productivity gains.
But I would love to know what the appropriate testing strategy would be
to prove whether Spring's template implementations of these data service
layer frameworks are thread-safe.
Or does Spring have a series of tests in its source code that prove it
already? (Unlikely methinks).
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by Christian Bollmeyer <ja...@christianbollmeyer.de>.
On Thursday 01 September 2005 19:26, Larry Meadors wrote:
> iBATIS is 100% thread-safe.
>
> Larry
>
>
> PS: can you point me to a good example of a Spring-based DAO
> implementation?
Hm...IMHO one good example would be the JPetstore sample
app that comes with the Spring distribution, for instance.
Good in particular, as its not overly complex, plus you can
compare it to the 'traditional' iBATIS JPetStore app. The
architecture has slightly changed (the former 'service'
functionality now rather completely wandered underneath
'domain.logic', in the Facade implementation, which
is IMHO ok in this case, as it's mostly delegating everything
anyway). This is one of the samples I profited the most from
when evaluating Spring. Another good starting point would be
Matt Raible's AppFuse, which is basically for Hibernate and
a little bit more complex. Those two are kind of my 'reference
samples' when it comes to Spring :-) Note that in both cases,
the DAOs are very lean and don't contain any messy
synchronization code.
But IMHO the really cool thing about IoC (not to mention the
AOP functionality) is that you finally can achieve really
loose coupling throughout your entire app, and its simple.
In fact, we could replace virtually anything in our current
app by a different implementation, declaratively (apart
from providing the new implementation class, implemen-
ting the same interface). Another benefit is that Spring
is non-intrusive by design and you can happily stick to
the technology stack you already know it works. For
instance, we still use Struts/Tiles instead of Spring MVC
or JSF. Clearly worth a look, but be warned: if you've
used it once, you won't ever want to go back :-)
-- Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by Larry Meadors <la...@gmail.com>.
iBATIS is 100% thread-safe.
Larry
PS: can you point me to a good example of a Spring-based DAO implementation?
On 9/1/05, Christian Bollmeyer <ja...@christianbollmeyer.de> wrote:
> 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" <pa...@yahoo.com>
> To: <us...@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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: DAOs in service methods
Posted by Christian Bollmeyer <ja...@christianbollmeyer.de>.
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" <pa...@yahoo.com>
To: <us...@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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org