we use DOA's as singletons since 3 years in prod, without any issue.
Again, a DOA will never have a state, why?
A DOA should have methods like "List<Person> getPersonsBornInYear(final
int year)" and every selection criteria gets passed as parameter. If you
consider a method like
"Order getOrder(final long orderId)"
the interesting part of the story begins: You have to make sure to never
show orders of other persons, so lets assume you are passing the PK of
the order as URL param, people start playing with this URL param
immediately, trust me. Therefore you have to make sure the order belongs
to the person logged in. Now you can either pass the logged-in person's
id and you get something like
"Order getOrder(final long orderId, final long pkOfUserLoggedIn)"
and "pkOfUserLoggedIn" is the id stored in your WebSession after
successful login. Now cheating is now longer possible. In case you use
PerThread DAO's you can inject the pkOfUserLoggedIn in your CTOR and
minimize parameters to be passed to your methods, but I won't consider
this as state.
BTW: personally I try to never use setters but fullly rely on CTOR
injection and protected/private final class members. But this is a
matter of taste...
Jens
Am 15.09.12 02:54, schrieb George Christman:
Thank You Carsten for your explanation. It definitely helps and I'll
definitely check out your suggestions.
Does anybody have any suggestions in regards to DAO's? Should the scope be
set to Perthread or should DAO services be left as singletons? I had an
issue last week with a multi thread import process which resulted in my
hibernate session having lots of issues. After learning about service states
today, I'm thinking this topic may have something to do with my issues last
week?
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Sevice-State-Stateless-tp5716278p5716294.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
