Am Samstag, den 11.11.2006, 09:14 +0000 schrieb Danny Angus: > On 11/11/06, Serge Knystautas <[EMAIL PROTECTED]> wrote: > > > Yeah, I'm biased, but I like think this is part of the advantages of > > just dependency injection. > > I'm still waiting for someone to give a sensible DI example that would > show how we deal with the fact that there can be an unlimited number > of unknown dependancies.
IMO exactly "unlimited number of *unknown* dependencies" is a strong argument for DI. In a big application it is important to know the dependencies exactly. > Service location allows the consumer of the services to look them up > as needed, DI requires that the container be made aware of the > dependance and invoke some mechanism to inject an instance which > satisfies it. Making aware a container of dependencies means mostly xml. This is just like a formal documentation of the dependencies. You should probably do that even when you using a service locator. I don't consider it as problematic that the format differs in different frameworks. They are quite similar and the process is not error prone. Invoking some mechanism means just calling setters. Likely inside some kind of factory. I don't see any magic there. :-) The whole procedure is probably just as easy as dealing with JNDI. IMO even when using JNDI the Bean should be configured through setters by calling a corresponding method or using a factory. (Funny enough: This could even be done by using a generic factory and xml ;-) This way the consumer had full control and could decide whether to use DI or JNDI. Also lookup up services as needed is more flexible I think it is more save to check dependencies at initialization. With DI you can do that even without creating any instances. > In what way is injection preferable to lookup? e.g. - who is affected when I change service A? - using a wrapper when Mailet X needs a special behavior of service B - different implementions/instances of Service C for Mailet Y and Z. - defined, full control of lifecycle: who is instantiated when? - possibility of adding support for different service locators. - Testing: being able to make use of Mocks - If you just want to use very few Mailets in a small tool you could wire up deps yourself. Another point is that a Mailet should concentrate on it's own business. Looking up and checking dependencies is IMO out of scope. If you do that in every single component it is not very DRY. Conclusion: I would not like to see service locator pattern as the default for looking up services in James. If it is really wanted/needed it could be a compromise to publish James services supplementary by JNDI and extend Mailet implementations with the ability of using JNDI for looking up dependencies. (I'm convinced this could be done in a clean, separate way without blowing up existing code) Following the trends we should keep OSGi in mind which offers another service locator mechanism. Joachim
