Nov 14th, 2005, 01:56 AM
Dependency injection becoming configuration injection?
I'm pondering on some design issue and would like some feedback. In a current project, we decided to use some of Spring to build up our beans and wire them together. That works perfect.
Basically, we're using a bunch of DAO's, with the underlying data-source differing from LDAP to a remote SOAP service to a local jdbc db.
We wire the appropriate implementation together in our application context, and when we want to test locally, just inject some stub implementation instead of the real thing.
Now one of us took that a tad further and decided to inject implementation-specific configuration parameters into the beans as well. For instance, if the implementation needed is one that calls a remote SOAP service, stuff like the username/password/endpoint url all get injected through the application content xml file.
These parameters of course are implementation-specific.
It used to be that each implementation read it's configuration from a properties file (either a separate one or an application-global one).
I can't seem to make up my mind but somehow it doesn't feel right. Dependency injection seems to be about wiring beans together so client code doesn't have to be aware of the actual implementation, just code against the interface.
This is more like configuration injection?
On one hand, our DAO's that read from the db do get their DataSource injected (so we can use the pooled one in the appserver and a simple one during local testing), that feels ok. But having usernames/passwords/url's/authentication method and all injected as well...