I looked into the wicket London presentation/code and databinder.net and it all makes sense but it looks like then my wicket forms/components are tied directly to the database. When I submit a form then the data is persisted but I don't want this. I want to be able to call the data layer to retrieve data or to persist data and not care that a form is tied to it or not. I also need to be able to get data to populate lists or tables on a page.
I currently have my project set up like: Data objects - POJOs to hold data that comes from or will be persisted to the db Data Access Objects - objects to get and persistent data using hibernate using the data objects Business Logic - helper classes to access the data access objects if additional logic needs to be performed before persisting to the db. Wicket Pages - all my wicket pages. The pages call the data access objects to retrieve data to display on pages and forms. The pages also handle the form submits and call the Data Access Objects to persistent to the db. In some cases I call the Business Logic layer to do the persistence. In the end I have data layer which I can re-use. The business logic layer which I can change as needed. Then the wicket pages which once they work I shouldn't need to touch if the logic changes or the data layer changes. This is what I think of as a true 3-tier architecture. I also am not using maven. I have eclipse running and added the jars to the project myself. If I need to use maven then I will but it seems like adding more stuff to something that should be very simple. Should I be doing something different in terms of my architecture to implement wicket? Everything is running fine for me except the lazy loading of data from hibernate. Not sure how my session size is going to look doing it this way either. Would prefer to have the smallest session size possible but this is a small app with little traffic for now so not that big of a deal. I am a wicket newbie and want to get this right as this is the first wicket project which will lead to a much larger higher traffic project that is currently planned to be developed using wicket. Thanks. -----Original Message----- From: Adrian Merrall [mailto:[email protected]] Sent: Monday, October 05, 2009 6:17 AM To: [email protected] Subject: Re: Wicket + Hibernate without Spring for lazy loading Google for a wicket london weekend presentation and follow up blog on loading jpa entity managers on demand. There have also been various posts relating to using the open session in view Hibernate filter. The JPA blog entry uses the requestcycle to prepare a thread local. The first call to use it creates the entity manager and keeps it in the thread local. The request cycle end request and exception methods handle the cleanup and close. Very brief description but if you google for the topics above it is all very well explained. HTH Adrian On Mon, Oct 5, 2009 at 6:22 PM, Petr Fejfar <[email protected]> wrote: > On Mon, Oct 5, 2009 at 5:12 AM, Jeffrey Schneller > <[email protected]> wrote: > > > I really don't want to bloat my code to implement Spring but if it is the > only way to do it then I will. > > When I've started learning of Wicket few month ago, my position was > the similiar: I'd like to avoid stuff like Maven, Spring etc... I > found out Databinder as well and tried it. But I was not able to make > it running with Hibernate, just with HSQLDB. > > So we've decided to continue with Spring, Maven... We've increased our > overhead little bit, but once we define beans, we do not care about > them any more. There was only one pitfall: manually invoking injection > of non-visual components. After few month I must say that Spring seems > to be the least problematic part of our projects. > > > Petr > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
