I’ll take your word for it as I haven’t dug deep in the MVC code, the 50% number just jumped off the page as such a huge number, I just can’t fathom how that’d even be possible.

But, MVC is a complex beast, so I shouldn’t be surprised that a bad design decision can start causing problems exponentially and before you know it they’ve got thousands of lines of horrible code used to get around a problem.

I’ve used constructor injection for over two years, but when I first started using an IoC container (a colleague introduced it into our application) I didn’t understand it at all. I was sceptical and thought it offered very little over normal construction. I was so badly wrong. The caveat is that you only get the benefits if it’s set up properly, you use a consistent mechanism of obtaining types (read: use the container!) and all of the types involved play ball.(don’t use new for dependencies, don’t use poor man’s DI etc.)

When you stumble upon a portion of your application that is going against the grain, it is tremendously irritating. We recently encountered a situation where our application had some functionality that was manually wired up (extensive use of new, static factories and poor man’s DI) which wrested control away from the container and did not go with the conventions.

I was meant to re-use the functionality in a slightly different context, but couldn’t. The result was that we couldn’t wire it up, configure or re-use the modules. I.e. it was not loosely coupled; it was like a little enclave of hard-wired stuff.

After they were refactored properly, the problem disappeared and all of the renegade functionality fell into line once more. I included the module, configured it differently and it worked beautifully.

What if you know that the class is always going to be using a specific implementation of the interface, but you don’t want the client code to know about this implementation? (but you still want the DI to be able to decouple the dependency in tests)

Or is it wrong to use the PMDI because you don’t want every code using instantiating the class to create the same code implementing the interface. The code you say is ‘saved’ in the real DI, is only added to the instantiating code. Unless you would always use an IOCC.

Sorry if i’m a bit slow here – I get that its not optimal with the constructor having the strong dependency, but you need to have the real coupling somewhere Would you then always instantiate it in the client code / IOCC.

If I’m opening too big a topic here, then feel free to post links to more info .:) it’s a very interesting topic.

Thanks

I think the 50% figure is a bit high, but it isn’t just because of a few extra constructors. They’re cutting a lot of public properties for unit testing through setter injection that do the “if null, return the default” anti pattern from years back, which in turn begets yet more [SuppressMessage] noise.

One of the other usages of an IoC container is to put things together, and they generally take care of lifecycle and scoping issues like objects that need to be scoped to a particular HttpContext or request. The MVC code doesn’t take advantage of this, and because of it, they need to write a lot more code to pass objects down inside an object graph to where it’s needed. *That’s* a bigger culprit for the “too much code” issue than the poor man’s DI.

‘The Gang of Four principle is “encapsulate the concept that varies”.’

How often do you honestly know what is going to actually vary a month from now? How about a year from now? Or ten years, assuming you’re writing valuable long-lived software?

I agree with the Gang of Four principle. Encapsulate the concepts that vary, or are likely to vary. I just can’t help but point out that, in any given code-base, literally everything tends to vary over time.

What you call “runaway DI”, I call extremely modular testable code that is predictable and loosely coupled. The “poor man’s DI” that was illustrated in this article would provide no value to me. I may as well not DI at all, because it actually ensures that components can (and will) be constructed instead of injected. This leads to tight coupling that can slow down development cycles, inhibit testing, and just plain make my day bad.

Others may have other experiences, and your mileage may vary, but I think it’s far past “religious debate” at this point. The strengths and weaknesses are well known, and it’s just an honest professional discussion on how far each of us believes is appropriate.

In other words, dependency injection is providing the implementor, whereas inversion of control is invoking an implementor.

Pop open the code, and check out how much of it is passing stuff around, context objects everywhere, factories, static gateways, etc etc. It’s a LOT of extra code that just wires things up versus actually adding behavior. PMDI alone doesn’t add extra code, it’s NOT doing DI that adds all that extra code, sorry I wasn’t clear about that.

http://www.lostechies.com/blogs/chad_myers/archive/2009/07/14/the-usual-result-of-poor-man-s-dependency-injection.aspx

Listen, I’m pro-DI/IoC, but we really have got to stop over exaggerating in an attempt to scare people into doing it.

I’m only coupled to the interface now, not the implementation. That’s what I’m trying to achieve. With DI, WHAT I’m coupled to is explicit, and called out in the constructor. That’s why I put DI in place on the first day of a project, it makes the coupling explicit.