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
