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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
