I've looked at the wiki post here about Spring:
http://cwiki.apache.org/WICKET/spring.html

I'm curious about 'best approaches' and if you bare with me I'll explain my
concern, but let me first address what I'll want to do..

In a WebApplication, SpringWebApplication, or possibly a WebPage, I'd like
to use a BusinessDelegate/serviceClass that in turn has a DAO that is Spring
injected into the BusinessDelegate. (I might also inject the
BusinessDelegate, but for now lets assume I'm not). So we have....


Wicket Object (as WebApp, Webpage, etc)
      |
      ------->   BusinessDelegate
                           |
                            ---------->  DAO //Spring injected

In a Struts application I'd just declare the beans I want to inject and into
what classes in my applicationContext.xml file.

Reading the wiki I understand that your wicket objects might be serialized
which creates some problems.

My first thought was to mark my BusinessDelegate transient in my wicket
object, and then when its needed, do the null check, and if null create a
new instance which would in turn use the LazyInitProxyFactory to load the
dao it needs.

The problem with this, though, is I'd now have to use wicket classes
(LazyInitProxyFactory) in my BusinesDelegate which I was hoping could remain
completely agnostic of the front end technology (if someone else in another
application wanted to use this delegate, I don't want them having to import
Wicket classes.)

Would it work instead if I injected the DAO in the BusinessDelegate using
the traditional approach (simple definition in  applicationContext.xml), but
then used the proxy approach in the Wicket object that would create the
BusinessDelegate:  (SomeBusinessDelegate)createSpringBeanProxy(
SomeBusinessDelegate.class, "myDelegate");  ?

(Slight drawaback to this is I'd have to define all the BusinessDelegates as
spring managed objects - but I can deal with that since it's not a bad
practice anyway.)

Reply via email to