if you feel DI/IOC for the testability is making you feel your code is hard to maintain, you could use a testability framework that eliminates the need for external dependencies.

With Typemock you can facilitate unit testing by eliminating dependencies by mocking, even if your dependency is on non-interface types, internal object creation etc.

This really isn’t supposed to be a sales pitch but you’re invited to visit our blog and website to learn more.

Hope it’s ok to post the resuls of our IRL conversation, i wanted to post my reply online in case anyone else is looking for the same answers:

If you use IOC (passing dependencies through the constructor), then testing becomes easy, but the production system looks a bit messy because everytime you need an X, you have to create a Y and a Z. This code gets duplicated everywhere you need to use one of your nicely tested objects. Yuk! You say it breaks the encapsulation OO rule, I say it breaks the “Single Responsibility Principle” and “Dont Repeat Yourself” too!

Yes: Factories are a great way to mostly solve these three problems. But I definately prefer using a Dependency Injection container. I have heard them referred to as “factories on steriods”. They are actually much easier to use, as well as being more powerful.

Hope you got a chance to read the article by James Kovacs (http://msdn.microsoft.com/en-us/magazine/cc337885.aspx) – it explains this stuff pretty well!

Cheers – Rob

Just one comment on your Q&A – there was a guy there who was asking you about DI breaking encapsulation. I happen to agree with him: Getting stuck having to expand some long lost project’s code that uses a lot of DI leaves you with a scavenger hunt to round up or reinvent all the right dependencies to feed the constructors. Fortunately, even if you haven’t completely embraced a DI framework, another easy answer is Factories. They can encapsulate the DI when you don’t want the consumers of your classes to have to be responsible for the dependencies.