Monday, July 04, 2011

Configuration-driven IoC why?

I've recently gone off configuration-driven IoC in a big way. It certainly has it uses (particularly in web applications, I've found, and especially if you're selling them on). However it makes no sense at all for desktop apps. Usually you find that if you change the configuration, you're redeploying the app anyway - so why not have the configuration done centrally in code? I've never seen a non-programmer change configuration, so this costs you nothing and saves you a ton of supporting infrastructure.

Also, config-driven code tends to lead to the phenomenon of too much loose coupling. Since you have to obey the container's rules about initialization, you can't make compile-time assertions about dependencies, which can lead to a sort of "fire away and hope it's there" style of programming. And plenty of mysterious errors in apparently unrelated parts of the application.

Just my two cents, I'm not feeling particularly vehement about this one.


Post a Comment

<< Home