views:

190

answers:

5

I understand the basic concept of Dependency Injection. Rather than have a lot of global state, you instead pass around what you need to the constructors of your various objects.

But I don't understand how this concept can be applied to a framework? What does a Dependency Injection framework do for you and when should you use one?

+1  A: 

The main thing I use it for is that it lets me plug in new implementations of an object without having to recompile. I can just change a config file and my objects get connected together correctly.

David
+5  A: 

The framework hooks everything up for you based on some sort of config (whether that's code, an XML file etc).

It's plumbing, basically.

Many DI frameworks also include Aspect Oriented Programming, object lifecycle management etc, but the basics of DI are to get your application up and running with objects talking to each other.

Another way of putting it: the DI framework is the bit of code which calls the constructors and tells the whole thing to run when it's done :)

Jon Skeet
@Jon Skeet, but why wouldn't I be calling those constructors myself? I guess I don't understand the benefit of the indirection. If I create a program with some simple classes and create instances of them passing other objects, how does a DI make that any easier than doing it myself normally?
KingNestor
Code isn't always the simplest way of expressing this - and even if you *do* use code (e.g. with Guice) you can often express something just once: "When I want an authenticator, wherever it is, use <this>."
Jon Skeet
A: 

The best way to find out how they are useful is to try a few out. I've been meaning to give Spring.NET a try, it looks like a good implementation.

Dave Swersky
A: 

One thing I really like about AOP is that it is really easy to move between a development and production version. You can create very verbose logging and then basically flip an xml switch and it's gone.

Nick
A: 

One of the main advantages of using DI/IOC is to reduce coupling between different classes.

When you use the approach you have to configure hierarchy of objects, which express the dependencies you took out of their code. This can turn into a lot of code. Even if you use the code part of a DI framework, it can greatly reduce the amount of configuration by letting you configure in a more expressive way:

  • Whenever an ILogger is needed, use a FileLogger.
  • You can go even further with conventions, whenever an
    I[Name]Controller is requested
    replace it with [Name]Controller.
  • You can have it manage singleton objects for you. So your code is the same as with any other
    dependency, but the DI makes sure you get the same instance all the time

A couple structuremap configurations I use:

    ForRequestedType<ILogger>().TheDefaultIsConcreteType<NLogLogger>();
    //the following injects any property that has a type 
    //that implements IController. (overcomes a regular asp.net limitation with DI)
    SetAllProperties(
         p => p.TypeMatches(t => t.IsConcreteAndAssignableTo(typeof(IController)))
    );
eglasius