Which Dependency Injection technique should I use in dotnet?

views:

415

answers:

+3 Q:

Which Dependency Injection technique should I use in dotnet?

[Revision 5/14/09: I need this to target Dotnet 2.0 because of my deployment scenario]

I am new to Dependency Injection & IoC.

I see that there are a plethora of containers and libraries to help the process along.

What are the pros and cons of using these libraries. What is your favorite (dotnet) container and why?

What about rolling my own container for Dependency Injection?

Thanks,

Peter Stephens

I like MEF, mainly because it's going to be very well supported in .NET 4.0 (since MS has announced that they're using it for the base of DI in Visual Studio 2010).

It's also quite simple to use, especially for DI. Handling DI and Add-In scenarios is the main goal of that framework, so it's very clean and simple in those cases.

It works for IoC as well, but that isn't its primary goal.

Reed Copsey 2009-05-18 17:31:51

I have heard good things about MEF. I recently listened to a Hanselminutes podcast that gave a good overview: http://www.hanselminutes.com/default.aspx?showID=166"Managed Extensibility Framework with Glenn Block"

Peter Stephens 2009-05-18 17:42:35

I've been using it for a while now, and it works great. I particularly like the way it handles catalogs and injection - you get a lot of control if you want it, but it's also very easy to just "make it work". I like the approach they took with it, even over my own DI solutions I've written (http://plugintoolkit.net/), which I've now abandoned in favor of MEF.

Reed Copsey 2009-05-18 17:45:39

I wouldn't use MEF for dependency injection, since that is not what it's made for. There are better solutions for that, many of which can work with MEF.

Krzysztof Koźmic 2009-05-19 09:30:20

After thinking about this a little--I would love to use MEF in my app but not for DI. Rather I would use it for composability of my application layers. Unfortunately, my app is Dotnet 2.0 Winforms and is unlikely to change anytime soon, so MEF will not work with it and must be crossed off my list :-(

Peter Stephens 2009-05-19 12:34:01

Of course, Composability is very similar to Dependency Injection. The line blurs a bit :-)

Peter Stephens 2009-05-19 12:36:42

@Krzysztof Kozmic: I disagree - MEF is great for depedency injection - in fact, that's really ALL that it does. It handles all three forms (http://en.wikipedia.org/wiki/Dependency_injection), including interface injection, setter injection, and constructor injection. It is not a good general purpose IoC framework, but a great DI framework.

Reed Copsey 2009-05-19 15:08:01

Yes, MEF is not an IoC Container: http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx

Robert Claypool 2009-05-26 15:10:31

+1 A:

I use an IOC tool called StructureMap : Structure Map I found the tool to be very useful and easy to implement.

CSharpAtl 2009-05-18 17:32:28

StructureMap looks good too. Unfortunately the latest version doesn't seem to target Dotnet 2.0 :-(

Peter Stephens 2009-05-19 12:55:49

Yeah the later version uses a lot of lambda expressions...

CSharpAtl 2009-05-19 13:11:11

Spring.Net

Kai Wang 2009-05-18 17:33:48

This framework looks interesting. It seems to do a lot more than just IoC and DI. I'm not sure I want to solve more than the IoC problem at this moment though.

Peter Stephens 2009-05-18 17:50:24

The Unity Application Block

blu 2009-05-18 17:35:22

Nothing wrong with the Unity Application Block. It also supports Dotnet 2.0 Woohoo!

Peter Stephens 2009-05-19 13:19:13

You can use Common Service Locator in your code, where it needs to call the container explicitly. This way if you're unhappy with the chosen framework you can switch it by pluging in the new one.

bbmud 2009-05-18 18:22:26

This looks like a possibility. Abstracting the abstraction layer is a nice concept :-) It also appears to support Dotnet 2.0.

Peter Stephens 2009-05-19 13:18:45

+3 A:

If you need only Dependency Injection probably AutoFac will be the best option, since it's small, quite simple and logical. It should not be to hard to grok.

Once you get that, and you feel the need for more mature product (that can do other things than simply DI) I'd suggest taking a look at Castle Windsor, which is pretty powerful out of the box, very well designed, and customizable. If you don't like that, I've heard good things about StrcutureMap.

Krzysztof Koźmic 2009-05-19 09:29:04

This looks interesting. It also targets Dotnet 2.0, though it requires a 3.5 build environment. I will definitely consider this.

Peter Stephens 2009-05-19 12:53:07

If you want to target .NET 2.0 in Windsor, there is a tag in the repository that supports .NET 2.0 All newer versions target v3.5sp1

Krzysztof Koźmic 2009-05-19 14:13:42

The version targeting .NET 2.0 is almost identical to Windsor 2.0 in terms of features.

Krzysztof Koźmic 2009-05-19 14:14:18

I haven't made up my mind entirely yet, but I'm leaning towards AutoFac. I might couple it with the Common Service Locater, but I'm not sure yet. I probably need to write some test cases to see how it will all fit together.

Peter Stephens 2009-05-20 13:01:46

+1 A:

After some more research: Ninject seems to be a useful alternative. And it supports Dotnet 2.0. And it doesn't require massive XML configuration.

Still trying to figure out Best Practices for having a different DI configuration for the Production and Unit Testing environments.

Peter Stephens 2009-05-20 15:57:09

+1 A:

Found another thread on this topic here

Peter Stephens 2009-05-20 16:16:00

ansaurus

tags:

views:

answers:

Which Dependency Injection technique should I use in dotnet?

related questions