http://vtd-xml.sf.net

If you keep reading the line passed the three periods in a row the rest of the statement clears it up, I’ll respond here without the three periods but a comma instead.

“100% DI’d code will be more effort to maintain because it would be in C# too, if not for that fact the language is so “structured” that the flexibility and testability benefits gained far outweigh the slightly increased cost (which is only brought down with the awesomeness of auto registering components). In a language already with flexibility and testability whether you use DI or not AND without auto registering IoC containers the cost to maintain a full DI code base is I’d argue unacceptable.”

So for example when I use IoC, I autoregister almost everything. My registration lines are maybe 10 or 12 for large code bases, and those are to handle the edge of the system typically.

When I didn’t autoregister and instead maintained huge XML files (or explicit code later) the pain was quite severe. I was still willing to have this because the benefits in flexibility still far outstripped the cost. But trust me I was VERY happy to have auto-registration later on, its something the Java community has completely missed the boat on from what I’ve seen.

I think this is a throw away comment and do not agree. Could you explain what you mean further?

To me I think having all you dependencies created in a single place is vastly easier then having them littered through the codebase.

@Daniel I think there is a kernel of truth, but its more like you can’t be a great chef until you can make a proper omelet. You have to understand the SOLID principles well enough to know when to apply them and Bob Martin has often talked about them not being a dogmatic thing.

I never thought about monkey patching as a useful way to do dependency injection, which, incidentally, still remains dependency injection, no? It’s still a technique you can use that you must remain aware of. So maybe SOLID becomes SLID?