I use the same setup as you, but I add the use of the OpenEntityManagerInViewFilter. I still use only Spring services from within Wicket (as much as possible), but the domain objects can be as full featured as needed because a Hibernate session is always open when Wicket is using the services.
On Thu, May 28, 2009 at 9:49 AM, Kent Larsson <kent.lars...@gmail.com>wrote: > You mean @SpringConfigured("something") like in the linked article? > > On Thu, May 28, 2009 at 3:41 PM, James Carman > <jcar...@carmanconsulting.com> wrote: > > In your entities, you don't use @SpringBean. You use > @Configurable/@Autowire. > > > > On Thu, May 28, 2009 at 9:38 AM, Kent Larsson <kent.lars...@gmail.com> > wrote: > >> Hi, > >> > >> Our current architecture: > >> --- > >> > >> We're currently using a 3-tier architecture (presentation, > >> service/business and persistence) consisting of Wicket (+ a little > >> Spring), Spring and Spring + Hibernate: > >> > >> Wicket: > >> > >> Does presentation, we're not inside a transaction / Hibernate session > >> so all used fields must be loaded by Spring. We call Spring singleton > >> beans and annotate those fields with @SpringBean. > >> > >> Spring: > >> > >> In the service layer we have Spring singleton beans, services, which > >> are called from the Wicket layer. We have our transaction / Hibernate > >> session boundary at this layer. We call DAO's from this layer. > >> > >> Spring + Hibernate: > >> > >> Our DAO's are Spring singleton beans which performs database > >> operations using HibernateTemplate. > >> > >> And common to all the layers are our entities. We use the @Entity > >> annotation on them (not XML), from the Wicket layer we just use the > >> accessor methods making sure that the relevant fields are loaded (as > >> we would get an exception if they were Lazy and not yet loaded). Our > >> entities are stupid, they lack logic and are used mostly like a struct > >> in C/C++. > >> > >> I think the general pattern is pretty common for Java EE and Spring > >> based web applications (feel free to disagree!). Yet it's classified > >> as an anti-pattern by Martin Fowler as we are using mostly procedural > >> programming and have an anemic domain model ( > >> http://en.wikipedia.org/wiki/Anemic_Domain_Model ). > >> > >> What I would like: > >> --- > >> > >> I would like to use a more OOP approach and have logic in our current > >> entities, creating a rich domain model. For that to work in all cases > >> they need to be able to load and save data. I would still use a Spring > >> singleton bean's for different services. But instead of changing the > >> entities like structs they would be rich objects capable of chaning > >> themself's and other objects. > >> > >> I found this article very interesting: > >> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 > >> > >> But how would something like that work with Wicket? Could I just use > >> @SpringBean like I'm currently doing but use it on both "entities" and > >> Spring singleton services? > >> > >> For me this has a purely practical benefit, as I could use some > >> inheritance in the domain object model to create different variations > >> of logic and not just data. Wicket feels quite agile and nice to work > >> with, but I still feel that the current architecture is a bit stale > >> and seldom supports elegant OO solutions (that said, of course things > >> can still be solved elegantly, I just think it would be easier if I > >> could do it in a more OO oriented way). > >> > >> Comments? What are the pros and cons of this kind of architecture? > >> > >> All comments are greatly appreciated! > >> > >> Best regards, Kent > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >