Design question. LAZY loading of fields in JPA/Hibernate enteties and Wicket. How do you handle it? Any way of not using DAO's?

[Kent Larsson <ke...@gmail.com>]

Hi,

== Background ==

In a previous non-wicket project I was involved in we had a three (or four,
depending on how you see it) tier archiecture:

1. Persistence using JPA (using Hibernate as persistence provider and have
it working against a MySQL database)
2. Business logic inside "manager classes" using EJB Stateless Session Beans
3. Presentation using Servlet+JSP

When the users made actions [3] our servlets called business methods [2]
which in turn executed logic on objects and made CRUD persistence operations
[3].

This worked pretty well. But we had some problems with LAZY loading of
fields in enteties in our presentation layer [3]. We exclusively used the
transaction support of the stateless session beans in the EJB framework and
the presentation layer were never supposed to have to do any direct
persistence operations. It should all be done from our bussiness tier.
Still, when the presentation layer tried to getXXX() certain fields
accessing persistence was necessary. These accesses failed as we were
outside of a persistence context. We could think of these solutions:

1. Start doing persistence operations in our presentation tier. So that the
getXXX() methods could be called and the persistence retrival would be
successful. We decided against doing this as we wanted to keep our
presentation layer clean of such operations.
2. Load everything immediately after retrival or after a certain method from
our business layer [2]. We decided on created a separate method for this,
which would be called from the presentation layer [3] before it did anything
with enteties. These methods had the form XXX
retrieveAllLoadedVersionOfXXX(XXX xxx). Where XXX could be DogHouse and xxx
an instance of DogHouse. It worked. The downside was that we needed to have
these special methods in our business layer which were there only because of
our choice in persistence. Not a crystal clear layer separation. But we
thought it was good enough.
3. Start using Data Access Objects (DAO's) and for each entity have a DAO
which acted as a stupid data carrier. Then we would pass a clean POJO from
our business layer [2] to the presentation layer [3]. And not pass a proxy
object as you otherwise would have to.

== Wicket related design question ==

How do you solve this in your Wicket based designs? I would like to hear the
relation between your Wicket models and JPA/Hibernate in your designs. Do
you use some other framework to easen your burden? If so, how and why? Do
you use Java EE for anything? If so, why? If it's possible I would like to
have a design without DAO's. At least DAO's I have to create and fill with
data myself.

Best regards,
Kent

Re: Design question. LAZY loading of fields in JPA/Hibernate enteties and Wicket. How do you handle it? Any way of not using DAO's?

[Kent Larsson <ke...@gmail.com>]

I am not using Spring. But maybe it would be a valuable addition to the
technologies I should use. I will have a  look at it and see if it's
something I could have use for.

On Thu, Sep 25, 2008 at 12:44 PM, James Carman
<ja...@carmanconsulting.com>wrote:

> Kent,
>
> Are you using Spring?  If so, take a look at the OpenEntityManagerInView
> filter.
>
> On Thu, Sep 25, 2008 at 6:35 AM, Kent Larsson <ke...@gmail.com>>
> wrote:
> > Hi,
> >
> > == Background ==
> >
> > In a previous non-wicket project I was involved in we had a three (or
> four,
> > depending on how you see it) tier archiecture:
> >
> > 1. Persistence using JPA (using Hibernate as persistence provider and
> have
> > it working against a MySQL database)
> > 2. Business logic inside "manager classes" using EJB Stateless Session
> Beans
> > 3. Presentation using Servlet+JSP
> >
> > When the users made actions [3] our servlets called business methods [2]
> > which in turn executed logic on objects and made CRUD persistence
> operations
> > [3].
> >
> > This worked pretty well. But we had some problems with LAZY loading of
> > fields in enteties in our presentation layer [3]. We exclusively used the
> > transaction support of the stateless session beans in the EJB framework
> and
> > the presentation layer were never supposed to have to do any direct
> > persistence operations. It should all be done from our bussiness tier.
> > Still, when the presentation layer tried to getXXX() certain fields
> > accessing persistence was necessary. These accesses failed as we were
> > outside of a persistence context. We could think of these solutions:
> >
> > 1. Start doing persistence operations in our presentation tier. So that
> the
> > getXXX() methods could be called and the persistence retrival would be
> > successful. We decided against doing this as we wanted to keep our
> > presentation layer clean of such operations.
> > 2. Load everything immediately after retrival or after a certain method
> from
> > our business layer [2]. We decided on created a separate method for this,
> > which would be called from the presentation layer [3] before it did
> anything
> > with enteties. These methods had the form XXX
> > retrieveAllLoadedVersionOfXXX(XXX xxx). Where XXX could be DogHouse and
> xxx
> > an instance of DogHouse. It worked. The downside was that we needed to
> have
> > these special methods in our business layer which were there only because
> of
> > our choice in persistence. Not a crystal clear layer separation. But we
> > thought it was good enough.
> > 3. Start using Data Access Objects (DAO's) and for each entity have a DAO
> > which acted as a stupid data carrier. Then we would pass a clean POJO
> from
> > our business layer [2] to the presentation layer [3]. And not pass a
> proxy
> > object as you otherwise would have to.
> >
> > == Wicket related design question ==
> >
> > How do you solve this in your Wicket based designs? I would like to hear
> the
> > relation between your Wicket models and JPA/Hibernate in your designs. Do
> > you use some other framework to easen your burden? If so, how and why? Do
> > you use Java EE for anything? If so, why? If it's possible I would like
> to
> > have a design without DAO's. At least DAO's I have to create and fill
> with
> > data myself.
> >
> > Best regards,
> > Kent
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org<ht...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org<ht...@wicket.apache.org>
>
>

Re: Design question. LAZY loading of fields in JPA/Hibernate enteties and Wicket. How do you handle it? Any way of not using DAO's?

[James Carman <ja...@carmanconsulting.com>]

Kent,

Are you using Spring?  If so, take a look at the OpenEntityManagerInView filter.

On Thu, Sep 25, 2008 at 6:35 AM, Kent Larsson <ke...@gmail.com> wrote:
> Hi,
>
> == Background ==
>
> In a previous non-wicket project I was involved in we had a three (or four,
> depending on how you see it) tier archiecture:
>
> 1. Persistence using JPA (using Hibernate as persistence provider and have
> it working against a MySQL database)
> 2. Business logic inside "manager classes" using EJB Stateless Session Beans
> 3. Presentation using Servlet+JSP
>
> When the users made actions [3] our servlets called business methods [2]
> which in turn executed logic on objects and made CRUD persistence operations
> [3].
>
> This worked pretty well. But we had some problems with LAZY loading of
> fields in enteties in our presentation layer [3]. We exclusively used the
> transaction support of the stateless session beans in the EJB framework and
> the presentation layer were never supposed to have to do any direct
> persistence operations. It should all be done from our bussiness tier.
> Still, when the presentation layer tried to getXXX() certain fields
> accessing persistence was necessary. These accesses failed as we were
> outside of a persistence context. We could think of these solutions:
>
> 1. Start doing persistence operations in our presentation tier. So that the
> getXXX() methods could be called and the persistence retrival would be
> successful. We decided against doing this as we wanted to keep our
> presentation layer clean of such operations.
> 2. Load everything immediately after retrival or after a certain method from
> our business layer [2]. We decided on created a separate method for this,
> which would be called from the presentation layer [3] before it did anything
> with enteties. These methods had the form XXX
> retrieveAllLoadedVersionOfXXX(XXX xxx). Where XXX could be DogHouse and xxx
> an instance of DogHouse. It worked. The downside was that we needed to have
> these special methods in our business layer which were there only because of
> our choice in persistence. Not a crystal clear layer separation. But we
> thought it was good enough.
> 3. Start using Data Access Objects (DAO's) and for each entity have a DAO
> which acted as a stupid data carrier. Then we would pass a clean POJO from
> our business layer [2] to the presentation layer [3]. And not pass a proxy
> object as you otherwise would have to.
>
> == Wicket related design question ==
>
> How do you solve this in your Wicket based designs? I would like to hear the
> relation between your Wicket models and JPA/Hibernate in your designs. Do
> you use some other framework to easen your burden? If so, how and why? Do
> you use Java EE for anything? If so, why? If it's possible I would like to
> have a design without DAO's. At least DAO's I have to create and fill with
> data myself.
>
> Best regards,
> Kent
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org