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
