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
>
>
