You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Chris Lewis <ch...@bellsouth.net> on 2007/10/29 08:37:52 UTC
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Davor Hrg <hr...@gmail.com>.
session is just interface,
the instance you get is a proxy,
which redirects each method call to
the instance in current thread.
Davor Hrg
On 10/29/07, Chris Lewis <ch...@bellsouth.net> wrote:
>
> Sorry, this just sounds to magical. My DAO explicitly takes a Session -
> org.hibernate.Session - and holds that reference for its entire life.
> Basic code:
>
> import org.hibernate.Session;
>
> public class UserDAOImpl implements UserDAO {
>
> private Session session;
>
> public UserDAOHibernate(Session session) {
> this.session = session;
> }
>
> //....
>
> }
>
> How can this session, which is declared as (and passed in as) an
> org.hibernate.Session, be 'fresh' after multiple requests?
>
> Davor Hrg wrote:
> > yes, that's right,
> >
> > that proxy will handle PER_THREAD scope
> >
> > Hrg Davor
> >
> > On 10/29/07, Chris Lewis <ch...@bellsouth.net> wrote:
> >
> >> 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 <ch...@bellsouth.net>
> >>> 29.10.2007 08:37
> >>> Bitte antworten an
> >>> "Tapestry users" <us...@tapestry.apache.org>
> >>>
> >>>
> >>> An
> >>> Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >
> >
>
>
Re: Antwort: Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Chris Lewis <ch...@bellsouth.net>.
That is nice :-). Thanks for the tips - I've just been poking around the
source.
chris
Kristian Marinkovic wrote:
> it is a proxy that implements the org.hibernate.Session interface :)
>
>
>
>
>
> Chris Lewis <ch...@bellsouth.net>
> 29.10.2007 13:37
> Bitte antworten an
> "Tapestry users" <us...@tapestry.apache.org>
>
>
> An
> Tapestry users <us...@tapestry.apache.org>
> Kopie
>
> Thema
> Re: Antwort: T5: 'wrapping' hibernate DAOs as services
>
>
>
>
>
>
> Sorry, this just sounds to magical. My DAO explicitly takes a Session -
> org.hibernate.Session - and holds that reference for its entire life.
> Basic code:
>
> import org.hibernate.Session;
>
> public class UserDAOImpl implements UserDAO {
>
> private Session session;
>
> public UserDAOHibernate(Session session) {
> this.session = session;
> }
>
> //....
>
> }
>
> How can this session, which is declared as (and passed in as) an
> org.hibernate.Session, be 'fresh' after multiple requests?
>
> Davor Hrg wrote:
>
>> yes, that's right,
>>
>> that proxy will handle PER_THREAD scope
>>
>> Hrg Davor
>>
>> On 10/29/07, Chris Lewis <ch...@bellsouth.net> wrote:
>>
>>
>>> 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 <ch...@bellsouth.net>
>>>> 29.10.2007 08:37
>>>> Bitte antworten an
>>>> "Tapestry users" <us...@tapestry.apache.org>
>>>>
>>>>
>>>> An
>>>> Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>>
>
>
>
>
Antwort: Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
it is a proxy that implements the org.hibernate.Session interface :)
Chris Lewis <ch...@bellsouth.net>
29.10.2007 13:37
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
Tapestry users <us...@tapestry.apache.org>
Kopie
Thema
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Sorry, this just sounds to magical. My DAO explicitly takes a Session -
org.hibernate.Session - and holds that reference for its entire life.
Basic code:
import org.hibernate.Session;
public class UserDAOImpl implements UserDAO {
private Session session;
public UserDAOHibernate(Session session) {
this.session = session;
}
//....
}
How can this session, which is declared as (and passed in as) an
org.hibernate.Session, be 'fresh' after multiple requests?
Davor Hrg wrote:
> yes, that's right,
>
> that proxy will handle PER_THREAD scope
>
> Hrg Davor
>
> On 10/29/07, Chris Lewis <ch...@bellsouth.net> wrote:
>
>> 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 <ch...@bellsouth.net>
>>> 29.10.2007 08:37
>>> Bitte antworten an
>>> "Tapestry users" <us...@tapestry.apache.org>
>>>
>>>
>>> An
>>> Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Chris Lewis <ch...@bellsouth.net>.
Sorry, this just sounds to magical. My DAO explicitly takes a Session -
org.hibernate.Session - and holds that reference for its entire life.
Basic code:
import org.hibernate.Session;
public class UserDAOImpl implements UserDAO {
private Session session;
public UserDAOHibernate(Session session) {
this.session = session;
}
//....
}
How can this session, which is declared as (and passed in as) an
org.hibernate.Session, be 'fresh' after multiple requests?
Davor Hrg wrote:
> yes, that's right,
>
> that proxy will handle PER_THREAD scope
>
> Hrg Davor
>
> On 10/29/07, Chris Lewis <ch...@bellsouth.net> wrote:
>
>> 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 <ch...@bellsouth.net>
>>> 29.10.2007 08:37
>>> Bitte antworten an
>>> "Tapestry users" <us...@tapestry.apache.org>
>>>
>>>
>>> An
>>> Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Davor Hrg <hr...@gmail.com>.
yes, that's right,
that proxy will handle PER_THREAD scope
Hrg Davor
On 10/29/07, Chris Lewis <ch...@bellsouth.net> wrote:
>
> 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 <ch...@bellsouth.net>
> > 29.10.2007 08:37
> > Bitte antworten an
> > "Tapestry users" <us...@tapestry.apache.org>
> >
> >
> > An
> > Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
right! so your daos can have singleton scope although
they have a session reference!!!
you can look at the HibernateModule source. there
is a very useful comment that explains how and why
it works
g,
kris
Chris Lewis <ch...@bellsouth.net>
29.10.2007 13:23
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
Tapestry users <us...@tapestry.apache.org>
Kopie
Thema
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
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 <ch...@bellsouth.net>
> 29.10.2007 08:37
> Bitte antworten an
> "Tapestry users" <us...@tapestry.apache.org>
>
>
> An
> Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Chris Lewis <ch...@bellsouth.net>.
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 <ch...@bellsouth.net>
> 29.10.2007 08:37
> Bitte antworten an
> "Tapestry users" <us...@tapestry.apache.org>
>
>
> An
> Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Antwort: T5: 'wrapping' hibernate DAOs as services
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
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 <ch...@bellsouth.net>
29.10.2007 08:37
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
Tapestry users <us...@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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org