It's rare that I hear someone using Inversion of Control (Ioc) principle with .Net. I have some friends that work with Java that use a lot more Ioc with Spring and PicoContainer.
I understand the principle of removing dependencies from your code... but I have a doubt that it's so much better.
Why do .Net programmers not use (or use less) those types of frameworks? If you do, do you really find a positive effect in the long term?
Lots of people use IOC in .NET, and there are several frameworks available to assist with using IoC. You may see it less in the WinForms side of things, because it's harder to just let the container wire everything together when you are designing forms in Visual Studio, but I can say that for server-side .NET applications, where I work at least, IoC is used very successfully.
Why use it in .NET? For the same reason you use it everywhere else. The 2 biggest things I like are:
Some other posts discussing the different IoC/DI frameworks available for .NET:
I use StructureMap for dependency injection and have only recently started using it with iBATIS.NET to inject our domain object mappers at runtime (and not through an XML config file, no thanks!).
I've seen immediate benefits. Creating interfaces for all our mappers (such as IPersonMapper) and then adding Moq allows me to write some pretty great database-free unit tests quickly and easily.
Previously (.NET 1.0) I wrote my own plugin system mainly to learn about reflection. Since that time I've implemented some sort of IoC in my projects. Its only recently I started using IoC for making unit tests so much less painful to write. I couldn't imagine doing it any other way at this point.
IoC is not really that commonplace in .Net up until now. And it has everything to do with Microsoft and there promotion campaigns they did. up until now they were more emphasizing the RAD capabilities of VS and in the meanwhile the forgot to promote things like IoC and Di but now they have their own framework called Unity and with the work they did on ASP.Net MVC.
So I guess the majority of people will start to use things like that. Because know they have a MS alternative to use.
And I use StructureMap.
It's getting more common. My current project uses Spring, and on my previous project we used Castle Windsor.
Now I'd like to use the 'convention over configuration' idea, to prevent all those complex XML declarations.
There are a lot theories related to the use of IoC .NET. I think there are a fair amount of developers that don't have the experience in the area. They didn't come from a Java background. They came from a classic ASP, and a VB6 background. Also, Microsoft didn't really promote the use of IoC up until recently.
Further, using IoC assumes several things. First, you must understand what it's used for and what you're getting out of it. Secondly, you must develop your code so that an IoC container can actually be used.
IoC is more than just using another item in the toolbox. It's about knowing how to use, knowing when to use it and maturing as a developer.
As it relates to .NET, I've several IoC containers. I've used Windsor, StructureMap, Unity and, most recently, Ninject. Keep in mind, though, I haven't used all of them in real applications. I like to play around and see what's going on out there. I've found that the market for IoC containers .NET is quite good.
I use it to allow my Unit tests to substitute Mock Classes (simulating actual production classes) for upstream dependant objects so that my unit tests truly only execute and test the code in the one class.method they are written to test.
Try LinFu.IOC 2.0:
http://www.codeproject.com/KB/cs/LinFu_IOC.aspx
It's one of the most flexible IOC containers out there, and like Ninject, there's no XML file to maintain. Unlike Ninject, however, LinFu doesn't force you to write any binding code to wire up your dependencies together. Take a look! :)