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 <[EMAIL PROTECTED]>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 <[EMAIL > PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[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]<https://mail.google.com/mail?view=cm&tf=0&[EMAIL PROTECTED]> > For additional commands, e-mail: [EMAIL > PROTECTED]<https://mail.google.com/mail?view=cm&tf=0&[EMAIL PROTECTED]> > >
