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
