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]
