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
