Comments on: Dependency Injection in ASP.NET MVC: Controllers

By: RyanAnderson

RyanAnderson — Fri, 23 Jul 2010 03:13:06 +0000

JB – Disregard…. Just read Henning Anderssen post, and I concur… Likelyhood of DI con swap is nil… And IContainer is valuable… Gotta Love JM!

By: RyanAnderson

RyanAnderson — Fri, 23 Jul 2010 03:09:55 +0000

JB – If you encapsulate DI into its own library, you can wrap up your DI container and loosen the dependency on a specific DI container.

Something like this in your App_Start,
ControllerBuilder.Current.SetControllerFactory(new MyIsolatedDiContainerLib.StructureMapControllerFactory());
(excuse the poor naming conv…)
This way the reference to StructureMap could be eliminated.

That way, if another DI flavor comes that you like better, you merely need to swap it out in you isolated DI Lib.
Like what you guys do in CodeCamp Server, with the StructureMapControllerFactory in the isolated DI Lib.

By: bogardj

bogardj — Wed, 05 May 2010 12:58:31 +0000

@ulu

Good call! Yeah, I just ran into this the other day and was wondering the right way to go. The base class provides a nice implementation.

By: ulu

ulu — Wed, 05 May 2010 09:33:01 +0000

Rather than returning a null, I return base.GetControllerInstance(). This way, I get a more meaningful exception when I mistype the controller name.

By: Chris Nicola

Chris Nicola — Sat, 01 May 2010 19:11:56 +0000

Sharp Architecture has this feature out of the box using Windsor. I definitely recommend MVC and IoC newbs check it out.

By: Mac

Mac — Tue, 27 Apr 2010 20:28:44 +0000

I found the same thing with the common service locator. It’s a great idea in principle but it’s too restrictive in trying to utilise the flexibility of an IoC like structuremap. The inability to occasionally inject/override parameters pretty much killed it for me.

Agree with Henning about the testing with the IContainer, we switched to that approach and so far it works very well.

By: Chris Tavares

Chris Tavares — Tue, 27 Apr 2010 20:19:30 +0000

CommonServiceLocator was intended for use by libraries that needed / wanted DI services, but did not want to force their choice of container on their consumers. It was never intended to be used in applications. I agree, there’s pretty much zero reason to switch containers. And heck, if you did it right, changing the container wouldn’t actually touch that much code.

By: bogardj

bogardj — Tue, 27 Apr 2010 18:48:11 +0000

@Javier

I’ve tried to use it in several of our projects (OSS or otherwise), and the answer has been (so far) a different design, or different configuration option like exposing Func etc. No one seems to even be developing on it either.

By: Javier Lozano

Javier Lozano — Tue, 27 Apr 2010 14:31:12 +0000

I think what you meant to say was “Common Service Locator is pretty much useless for our needs”

In all reality, yes, using your IoC to its fullest, is the definitely the way to go since you can build the app to best use different features the container provides.

The big issue that some teams suffer is that they tend to get too hung up on the intersection between their IoC and the application rather than just embracing it and developing the app.

By: Henning Anderssen

Henning Anderssen — Tue, 27 Apr 2010 09:05:39 +0000

We had the same discussion recently on my current project, whether to use a common service locator / abstract away the IOC or to use the full power of an IOC.

We originally abstracted away Structuremap because of testing. At that time we only knew of ObjectFacotory.GetInstance and didnt know of the IContainer interface. Now that we know of the IContainer interface, the testability portion of abstracting away the IOC goes away.
Another argument for abstracting away the IOC is the possibility for changing the IOC later in the project. “Makes it easier to swap out the IOC” and all that stuff. However, the likelyhood that you will EVER change the IOC is extremely small, especially when using Structuremap. And if you decide to swap out the IOC, you’re likely to make changes in your code anyway.

We use the same method for creating our instances, and it works like a charm. There is only a few places where we have to resort to service location.