Is it worth setting up IoC for non-MVC projects in .Net?

Everywhere I look for information on Windsor or Spring.net its always in reference to MVC. Is there any point trying to implement it f开发者_JS百科or web forms projects or wcf?

It just so happens that the nature of an ASP.NET MVC web application lends itself extremely well to IoC because of the way it handles requests. You can say that the startup-request-response lifecycle of a web application, and the way ASP.NET MVC handles those things, correspond directly to what Krzysztof Koźmic calls The Three Calls Pattern and what Mark Seemann calls Register Resolve Release pattern.

There are ways, however, to follow this pattern even in application that do not directly lend themselves to it - e.g. in WinForms apps, Windows services etc.

<shameless_plug>

I wrote a blog post about Castle Windsor's TypedFactoryFacility that is a feature of Windsor that allows the container to be called, truly IoC style, without your code knowing it.

The typed factory facility makes Windsor capable of dynamically implementing interfaces, like e.g. ISomeFactory, delegating calls to the container's Resolve method underneath, thus allowing your code to depend only on the ISomeFactory interface.

</shameless_plug>

IoC is just as useful whatever kind of project it's in. The problems it solves (testability etc... etc...) aren't specific to any particular kind of project.

Inversion of Control (a.k.a. Dependency Injection or Third-party Connect) is just a way to enable loose coupling.

As far as I have been able to identify, there are only two ways to enable loose coupling: IoC or Service Location (which is an anti-pattern). If you want to enable loose coupling in any application, IoC is the way to do it.

Loose coupling gives you a lot of benefits:

• Testability
• Late binding
• Reduced complexity (SOLID)/better maintainability
• Extensibility
• Parallel development

It isn't tied to any specific architecture, pattern or type of application.

Yes, if the architecture calls/allows for it. It depends on the design of the whole application, not just the UI framework used.

For example, if the WebForms project throws everything into code-behind and is directly accessing the database from Page_Load and such, then using IoC (or any kind of re-factoring) is going to be difficult.

However, if the WebForms are, say, accessing services or are interacting with models which access services or use repositories, etc. then those back-end objects can be injected with a service locator of some kind, such as an IoC framework. Hooking into the constructor of the WebForms classes may not be easy (or even possible, I don't think I've ever tried it), but you can still resolve dependencies within the classes as needed (late-bound class properties, for example).

IoC has absolutely nothing to do with MVC. They are two completely different design patterns.

Whether or not you use IoC in an application depends on your design. YAGNI? Then forget about it. Lots of dependencies between classes that makes testing hard? Sign up immediately.

IoC frameworks don't care what kind of design pattern you use to implement your application. So MVC or 10k lines of code inside your aspx file, it doesn't matter.