Kris,
My DAOs are ignorant of Tapestry - I have no @Inject annotations in
them. Instead they receive the Session object in the constructor, so
technically they do have state. This is why I thought I might need to
configure them as per-thread. However it sounds like you are saying that
the Session that gets passed to my DAO constructor is actually a proxy
to the actual hibernate session, and that this proxy takes care of
getting a valid session. Is that right?
Thanks :)
Chris
Kristian Marinkovic wrote:
hi chris,
i did this too :)
it is not necessary to make your DAOs have per-thread
scope (as long as they dont have a state!... they souldn't anyway).
All you have to do is to inject the session. tapestry-hibernate
generates a session proxy object that will obtain the actual
session from a per-tread HibernateSessionManager.
g,
kris
Chris Lewis <[EMAIL PROTECTED]>
29.10.2007 08:37
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
Tapestry users <users@tapestry.apache.org>
Kopie
Thema
T5: 'wrapping' hibernate DAOs as services
Hello all,
I'm building out the persistence infrastructure of my T5 app and would
like some opinions on accessing my DAOs.
Summary:
I have DAOs for accessing my entities that provide common functionality
as well as prevent my higher-level web-app parts (pages/components) from
knowing about my persistence layer. That is, I won't be @Inject-ing
org.hibernate.Session instances, which while easy, would instantly tie
me to hibernate. Instead I'll be injecting my DAOs - or at least
top-level interfaces implemented by them (UserDAO, etc).
Now what I have to deal with is accessing my DAOs from my
pages/components. It seems to me that 'wrapping' them as per-thread
services would make this extremely easy. In reality I'm not actually
wrapping the DAOs - I'm simply binding them and tagging them as
per-thread. Each implementation takes an org.hibernate.Session in its
constructor, which if I understand correctly, Tapestry IoC supports
transparently (constructor type args that is).
What I end up with are DAOs that are ignorant of their role (as far as
their existence in Tapestry), and can be obtained by plain old Tapestry
IoC injection. The DAOs are thus created per-thread, but this seems
fairly logical to me as they should be cheap objects. They do hold
instance references to the Session, but as long as the DAOs are
per-thread this shouldn't present a problem.
Does this seem like a sane path or am I overlooking something major?
Thanks for the input!
Sincerely,
Chris
---------------------------------------------------------------------
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]
