Yes, my IDE nearly exploded with the weight of new code added to employ DI. I’m not sure how my machine was able to handle the extra order of magnitude of code created to support dependency injection.

Poor man’s DI requires _more_ coding, not less, as the example above showed. Poor man’s DI is by definition more coupled, as I am coupled to specific implementations, as opposed to abstract interfaces. I highly recommend you check out Uncle Bob’s Agile Software Development book, he explains far better than I how following the SOLID design principles improves your code.

Don’t worry – I was told about 80 times after I posted this that you guys explained this in the material.

This _is_ a valid pattern, as are all, and I think I need to explain where each is valid.

I did raise the point to “the Scotts” about the coupling issue – that DI will allow you know only the interface and not the implementation but the general feeling was that we’re not building the Stock Exchange and to try to introduce the concept of IoC while at the same time talking about DI seemed just a tad silly.

Sure using StructureMap is “better” – you know I agree with that. But the thing you’re missing here is understanding the pattern before improving it and if you were to read the tutorial I wrote exactly that: “we have an issue with this constructor …” but my guess is you didn’t. That’s OK, I’m used to it

It is a fine line to be sure – not every private field should be exposed. I have places where I keep a local cache in a dictionary – that shouldn’t be exposed. For me personally, my line is “does component X require component/service Y to fulfill its responsibilities”. I think the component/service distinction is important, too.

I will look into the Suteki code when I find the time. Sounds interesting.

And I was thinking that this is something we are forced to do when we decide to expose the DataContext. Which means our repository code now got more complex. In Suteki Shop, that’s propably what you need. But for a demonstration like Nerd Dinner, that’s overkill.

There is a finer point here, which I continously fail to articulate: Which types of dependencies should we expose, and which ones are ok to keep hidden? As we have seen here, some exposures come with a significant cost.

I am still of the opinion that a repository implementation is infrastructure code, while the repository contract is domain code. I don’t think infrastructure implementation should leak into the domain.

I can see NerdDinner becoming the next northwind.