Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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
newmost 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).