This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I just integrated spring with struts and I just wonder 'what's the big deal about IoC'? (I'm asking this in the most respectful way of course).
So, i take it I can do this from the action:
So, I defined the PersonManager in the applicationContext:
and the 'personManager' was initialized on startup.
My point is this: I could have done this on startup and add 'personManager ' to the 'session'.
When I ask for a service (say registrationService to persist a new user) I use a singleton and then I can write
a method (getRegistrationService) in the base class and it's accessible for any 'Action'
* can anyone give a better example (real-life) when to use IoC (or dependency injection).. a good solution for some problem?
First of all, you're not really using dependency injection there. DI means that the bean is injected *external* to the class. In your example the action is still managing the instantiation, the only difference being that the implementation is decided in an external configuration file. This is the weakest form of "DI" possible, if it would even be called that.
Consider this instead:The PersonManager implementation is still defined in a Spring config, as before. Here's the difference: now you can instantiate TheAction and set its PersonManager implementation in arbitrary code--like a unit test, or on action instantiation (like if you're using the S2 Spring plugin).
With the implementation decided by external means we can now play a lot of games with both the action and the PersonManager implementation. We could, for example, have a PersonManager implementation that always throws a specific exception. Or disallows login, or whatever--thus giving us the ability to create unit tests for any aspect of system functionality.
There are a million web references for IoC/DI--it's usually a situation where until you use it and understand why it useful you won't "get it", like Lisp macros. It's easier to understand by utilization. The first step is to understand what it actually *is*; hopefully the simplistic example above has at least cleared up your initial misconceptions.