CODEWITHSUNDEEP
springdependency-injectionwicket
Robin Wieruch
Robin Wieruch

Reputation: 15898

Wicket: Dependency Injection

I've some questions about DI in wicket:

Do I need DI, when my businesslayer (in this case my restful web service) already got spring DI?

Whats the difference between both?

Do I need Object AND Component DI in wicket?

When I read about DI it says that when my resource location will change I dont have to bother myself with it. What does it mean? Does the imported jar change? I think I didnt get this concept, although after reading several articles about it.

Upvotes: 1

Views: 1104

Answers (2)

tetsuo
tetsuo

Reputation: 10896

Do I need DI, when my businesslayer (in this case my restful web service) already got spring DI?

To get a reference to Spring beans, you could either use DI (@SpringBean) or get them directly from Spring's Application Context:

    WebApplication application = WebApplication.get();
    ServletContext sc = application.getServletContext();
    WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(sc);
    MyService myService = ctx.getBean(MyService.class);

Whats the difference between both?

Assuming 'both' means Spring's DI and Wicket's DI (wicket-ioc), Wicket's DI is aware of Wicket's lifecycle, and will make it work correctly.

What I mean is, Wicket will serialize the page after every request. If you use @Autowire to inject your dependencies into pages and components, it will either fail (if the injected bean is not Serializable), or serialize the whole bean along the page (which is probably an undesirable behavior).

When you inject a dependency into your components with @SpringBean, what will be injected is not the bean itself, but a serializable proxy, that will lookup the real bean on demand, and release it after the request (just like LoadableDetachableModel does with data).

If you lookup the service every time you need it, instead of injecting it, you won't have this problem, because no reference is held as class attributes.

Do I need Object AND Component DI in wicket?

Assuming 'Object' means 'Spring DI' and 'Component' means 'Wicket DI', yes and no.

Spring is much better at injecting services in general, and will work outside Wicket's request cycle (for exemple, in a Quartz scheduled job). wicket-ioc won't.

wicket-ioc+wicket-spring are simply a glue between Spring and Wicket. If you want to use dependency injetion in your components and pages, I think you should use it, due the way Wicket works.

I think since Spring 3.0, Spring's scoped proxies (<aop:scoped-proxy/>) are also serializable. They also lookup the bean on demand, just like wicket-ioc, and are not bound to Wicket's request cycle. The problem is, they are globally declared in the Spring configuration, so every instance of, say, MyService would be proxied, not only the instances injected into Wicket components. And, since Wicket components aren't injected (you call new every time you need them), 'traditional' Spring injection mechanisms won't work, you'll need something like @Configured and AspectJ weaving, or calling ApplicationContext.getAutowireCapableBeanFactory().configureBean(bean, beanName) on every component. It may be a problem or not, depending on your aesthetics sense :)

When I read about DI it says that when my resource location will change I dont have to bother myself with it. What does it mean? Does the imported jar change? I think I didnt get this concept, although after reading several articles about it.

In this case, 'resources' probably include both external resources - such as database connection pools - and bean implementations. If the IP of your database changes, and you have it hardcoded into a class, you must change the class and recompile it. If it is configured externally (in a XML or ,properties file, for example), you just need to change or replace it, which is a much safer operation.

What Spring does, in this case, is to offer a very flexible, generic way to do external configuration. It also removes the instantiation of service beans from the code, making it easier to change both the concrete class and its construction parameters.

Upvotes: 2

Nicktar
Nicktar

Reputation: 5575

O.K. several questions at once...

Do you need DI?

No. Wicket works perfectly without DI. For my part (and I'm a huge fan of DI) I use DI nearly exclusively to inject DAOs to my components. It's nice, It's easy but it's definitely not necessary.

Whats the difference between both?

Assuming you mean the difference between DI in Wicket and DI in your businesslayer... There is no difference I'm aware of.

Do I need Object AND Component DI in wicket?

That's a question I can't answer since I don't know what you're talking about.

About the last part. I don't know what resource locations may have to do with DI. When you're using for example Guice for DI, then you define your injected Objects at one central place (the module) and just annotate your classes accordingly. In case of wicket components, the Wicket-Guice integration makes sure, that the components are passed to Guice for Injection when they're created. For other objects the call to the Guice-Injector replaces new most of the time. That way, when you change one of your implementations you just modify one class (the module) and everything is taken care of (assuming the interface stays the same (the same interface not an unmodified interface).

Upvotes: 2

Related Questions