In case you haven't noticed, there is a bit of a debate going on over Dependency Inversion and Type Mocking, and the merits of each approach. Many bloggers have started to weigh in on it; so I thought I would join the fun.
I favor Dependency Inversion. This is not to say that both approaches don't have benefits - they clearly do, and neither side has produced completely ideal results, as was well stated by Aaron here:"...neither sides of the camp is producing Silver Bullets."
Jacob Proffitt (the originator of this discussion) has repeatedly sung TypeMock's praises - and rightly so, as it is a very powerful mocking tool. The fundamental problem I have is this: I refuse to allow my overall application design to be coupled to the availability of a commercial tool or product. My main goal, and hopefully the goal of all well reasoned developers out there, is to create application where the components are loosely coupled from each other, and the overall design is decoupled from the tools used to make it. Relying on TypeMock to achieve this seems like an dangerous bet. I can still achieve this loose coupling without any tools when I apply Dependency Inversion - it may not be the most enjoyable and I normally use tooling; however, I'm not required to, and should I change my tooling in the future it will be likely be less effort to do so.
One approach that I've used in the past is to use ambient service locators, similar to the Scope<T> sample on MSDN. This allows you to achieve some of the "aesthetic" (for lack of a better word coming to mind) qualities that I think both sides are striving for. You can still "inject" your dependencies - but you can do so without relying on the traditional approaches (constructors, methods, and properties). I strongly recommend you take a look at that sample.
Above all, it is the well-established, time-tested principles that we should want to stick to. Letting a vendor’s product drive your design and how you achieve adherence to those principles may be an unwise approach.