StructureMap 2.6.1 and ASP.NET MVC 2 Questions (from a complete beginner in DI)

Per a conversation with @Aaronaught on another thread, I've started converting my application to use Dependency Injection and the Repository patterns, but I'm a little stuck. I think I get most of the stuff and flow of the patterns, but I'm stuck on implementing StructureMap into ASP.NET MVC 2. The examples I've read seem to be out of date with the latest version of Structure Map which I'm using (2.6.1).

I'm hoping that someone can fill in the gaps based on the code I paste below:

public static class Bootstrapper {
    public static void Configure() {
        ObjectFactory.Configure(x => {
            x.For<DataContext>().Add(new DataContext());
        });
    }
}

With this I can get an instance of the DataContext from within my controller(s) with:

protected DataContext dc = ObjectFactory.GetInstance<DataContext>();

I know that's wrong to do, but I'm confused on how to avoid it. Moving on, here's the controller factory:

public class StructureMapControllerFactory : DefaultControllerFactory {
    protected override IController GetControllerInstance(
        RequestContext rc,
        Type ct) {
        return (ObjectFactory.GetInstance(ct) as Controller);
    }
}

I don't understand exactly what this does, but it's in the examples, so I'm replicating it. Can someone explain it to me?

Now from what I understand, there's supposed to be registries which if I understand correctly, globalize object instances such as the DataContext. Is tha开发者_如何学Pythont correct? If so, how do I go about writing the registry for StructureMap 2.6.1? The example code I've seen seems obsolete because when I write it I don't have the same options available to me (via IntelliSense), so I'm not sure how to write it...

I will really appreciate any help in filling in the gaps that I have.

P.S. My experience with Dependency Injection and Repositories is about 8 hours total.

UPDATE/CONCLUSION

Having read through @Pure's excellent explanation below and watching the tekpub video he referenced in a sub-comment I've opted out for Ninject over StructureMap.

I don't know if Ninject is better than StructureMap, but from my stand point it's definitely much easier to start out with and get going.

OK,

I'm sure Jeremy Miller will correct my post and give you the real truth, but the idea of having that custom Controller factory which uses StructureMap to create the controllers, is because the Controller class is the key class where the majority of the logic kicks off and takes place (Yes, there's action filters and stuff that happens before, but lets keep this simple) - and this needs to have all the dependencies pre-setup before any logic begins.

So the idea is this. If all the logic and magic-unicorn stuff happens in the Controllers methods, then when we first enter the method ... we need to have all our requirements already setup. More importantly, each method in any Controller shouldn't care about what requirement (ie. instances) it has .. just that someone, from somewhere. .. has already made this decision and given me all the important objects that we might require.

This is core of what DI/IoC is all about.

So lets use some really simple code to explain this, cause I'm not good at explaining things.

Lets assume we have the following method in the Controller :-

public ActionMethod Index()
{
   // List all Products.
}

Pretty simple. Just lists some products to the browser. So the first thing you need to ask is this -> what are Products? where do they come from? Well, the controller method doesn't ask this question at all. In fact, it DOESN'T CARE where they came from. It only cares that it has something that is a Product.

So when we are in this method, we also shouldn't care about where the product information exists at. We just want to do something with this things called Products'.

Ok .. so lets do something with it ...

public ActionMethod Index()
{
   var products = _myProductService.Find().ToList();

   // .. rest snipped.
}

Ok .. so far we now are asking some Service to find all the products and then list them. Kewl. Still, we don't care where these products originate from. Or even, what is this Product Service. That's the key -> We leave the DI/IoC to worry about that. All we care about is the fact that we have some ProductService which does some stuff with some products. In this case, it's going to Find all the products and then we ask it to List all the products, found.

So where does DI/IoC come into play?

This is the unicorn-magic part :)

When this controller was instanciated, it asked StructureMap :

"Oi! StructureMap! I need to create a HomeController. But The HomeController has at least one constructor.. and the most complex constructor it has (note: DI/IoC call this the most greedy constructor) lists a number of objects which it requires. So ... I need to create those objects first, then create my HomeController .. and pass those objects in.pass those objects in.

Lets look at the code...

public class HomeController : Controller
{
    private IProductService _productService;
    private ILoggingService _loggingService;

    public HomeController(IProductService productService, ILoggingService loggingService)
    {
       _productService = productService;
       _loggingService = loggingService;
    }

    public ActionMethod Index()
    {
        var products = _productService.Find().ToList();

        // rest snipped.
    }
}

whoa -- there's a few things going on here. Lets recap -> So StructureMap says:

I need an instance of a IProductService and an ILoggingService .. which I pass to the HomeController constructor ... can u give me those please?"

And StructureMap then says:

Ok .. first up -> an IProductService. Lets see here, U've mapped an IProductService to a custom class you made, called ReallyFastProductService. Kewl, i'll create one of those bad boys. Next, u've mapped an ILoggingService to an NLogLoggingService class ... nice! NLog wroxs, dude. So i'll also create one of those bad boys. Ok, i've now made those two instances. Finally! I can now make an instance of the HomeController you're after .. and then i'll pass those two objects i just made, into the HomeController constructor... and viola! here's the Controller instance.

... so now, u have the Controller instance.

.... and when u step into the Index() method, if u use the mouse and hover over the instances, they will be a ReallyFastProductService and an NLogLoggingService.

Awesome! So this means that the Index() method is never tightly coupled to a particular implementation of a class.

Now, u decided that u didn't like all the code you did in the ReallyFastProductService and decided to code up another one, that takes use of some new tricks and skills you just picked up. So now you make a 2nd class called, PewPewProductService, because it pwns. Now, if u change your StructureMap mapping from...

ObjectFactory.Configure(x => 
    { x.For<IProductService>().Add(new ReallyFastProductService());});

to

ObjectFactory.Configure(x => 
    { x.For<IProductService>().Add(new PewPewProductService());});

... suddenly, all the methods in that HomeController now refer to the logic in the new class you just built. No need to change any code in the Controller.

Catch the penny as it drops :)

Welcome to DI/IoC and why it kicks serious butt.