I am looking for a simple yet practical and robust IOC/DI framework for .net

I am going to use it in a project with less-experienced developer开发者_运维问答s so a complex framework such as Spring.NET is not an option. I was thinking about:

1. Ninject
2. Castle Windsor
3. StructureMap

Which would present a moderate learning curve without losing flexibility?

and another question - where is the correct place to put the configuration? Since the kernel/configuration on a 3-tier ASP.NET application (not MVC!!! all examples are using MVC :) )

The great thing about proper use of DI is that you can defer the decision about which DI Container to use until the last responsible moment. In application architecture terms, this corresponds to a so-called Composition Root, which is where you wire all depedendencies together. This is often the application's entry point.

Apart from the Composition Root, the entire application can be written without referencing any particular DI Container at all. You just need to follow well-known patterns and principles.

When it comes to pick a DI Container, I'm aware of these DI Containers for .NET:

• Castle Windsor
• StructureMap
• Unity
• Autofac
• Ninject
• Spring.NET

Personally, I have been happy with Castle Windsor so far, but I have yet to gain extensive experience with all of these containers.

Here's an ASP.NET (not MVC) Ninject sample:

http://davidhayden.com/blog/dave/archive/2008/06/20/NinjectDependencyInjectionASPNETWebPagesSample.aspx

I have used ninject and found it easy to bring new developers up to speed with it.

Consider to start with wiring by hand: see http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion . It gives less-experienced developers a better insight in the basics of IOC/DI.

I think you are being too hasty to reject spring.net. Spring offers an extremely flexible learning curve, so at the beginning it's kind of "you take what you want from it" approach.
You can start with the simplest-of-all IoC container, and later on move to aop, transactions, unit testing, or whatever you desire, so the complexity builds up gradually.

This was the #1 selling point at my last two jobs for using Spring. Additional points were:

• It doesn't force you to use its api or to bend your architecture. Again, this leads you to adapt its features at your own pace.
• Very extensive documentation.

When the project matures, so will your developers, so spring will come out handy at the end ... (at no cost in the beginning, in my opinion)

Autofac is my container of choice. It allows registration via lambda expressions for maximum flexibility (the link has some nice examples).

It also has a Silverlight-compatible version. I'm unsure if the other containers do.

As for placement, the container should be built during application startup. For an ASP.NET application, this would be in the Global.Application_Start method.

Autofac has ASP.NET integration which injects pages instances using the container you build during startup.

Have a look at http://funq.codeplex.com/ first of all it's extremely fast compared to windsor and other reflection based containers second of all it's very flexible but still has a very readable configuration (If you've gotten your head around Lamba expressions which should take to long any ways)

We use the managed extensibility framework. It is part of the .NET 4.0 framework (currently in release candidate), where you can find it in the System.ComponentModel.Composition namespace. The codeplex site is currently still the best source of documentation.

The focus of MEF is more on "extensibility" rather than "dependency injection", but it uses dependency injection to achieve this. For example, the visual studio 2010 code editor uses MEF to enable extensibility.

We use it as a DI framework and have not yet run into any problems (though I did need the dynamic instantiation sample which is not part of the core yet).

If you're yet familiar with any DI framework, I'd go with the Simple Injector.

It has a very simple API, that will get you started very quickly. Although simple, it still enables many advanced configuration scenario's. The library designed with migration in mind, which means that switching to another framework would is rather straightforward. To prove this point, there is an migration guide on the project's wiki.

In addition to Ninject, which is a great product, there are also two other options that I'm familiar with:

1. Microsoft's Unity. Some Alt.NET folks think it's a little on the big & complicated side. I've been using it for several months now as part of Prism (Prism is NOT required to use Unity. It's available stand-alone) and I've found it to be simple and straight-forward.
2. StructureMap. I've found StructureMap to also have a very gentle learning curve with fast ramp up.

Hope this helps.

I find StructureMap very usefull and intuitive to use. I played with Ninject a bit and found that less convenient, but YMMV. I would also recommend you use the common service locator as an intermediary between the actual implementation of your IOC and your application. When you want to switch your IOC/DI container later on, this is less painfull. There are adapters for StructureMap and Castle windsor. And I think from googling that there also is an adapter for Ninject 2 according to this blog.