02 July 2010 ASP.NET MVC, Castle Windsor, DI, HowTo, IoC robert.muehsig Edit

imageUm einem MVC Controller seine Abhängigkeiten (z.B. Repositories, Services etc.) über ein DI-Framework, wie z.B. Windsor Castle, reinzugeben muss man ein klein wenig am MVC Workflow rumschrauben. Glücklicherweise erlaubt das MVC Framework die Überschreibung der ControllerFactory.

Für die Testbarkeit - das Szenario

Wir haben den simplen HomeController:

    [HandleError]
    public class HomeController : Controller
    {
        private IFooService _fooService;

        public HomeController(IFooService fooService)
        {
            this._fooService = fooService;
        }

        public ActionResult Index()
        {
            ViewData["Message"] = "Welcome to ASP.NET MVC!" + this._fooService.Bar();

            return View();
        }

        public ActionResult About()
        {
            return View();
        }
    }

Dieser nimmt im Konstruktor eine Implementation von IFooService entgegen. Der FooService wird in der Index Methode gebraucht. In einer realen Anwendung könnte dies z.B. ein Repository sein.

Der FooService:

    public interface IFooService
    {
        string Bar();
    }

    public class DummyFooService : IFooService
    {
        public string Bar()
        {
            return "DummyFooBar";
        }
    }

Durch den Einsatz des Interfaces könnten wir dies z.B. in einem UnitTest mocken.

Knackpunkt: Die Objekterzeugung

In einer normalen Anwendung könnte man, wie z.B. in diesem Post erklärt, recht einfach über den IoC Container die Implementation reingeben. Allerdings wird ein Objekt zum HomeController vom MVC Framework erzeugt - dies übernimmt die DefaultControllerFactory.

Zum Glück kann man auch eine eigene ControllerFactory schreiben. So würde es im Grunde aussehen:

// nur für Demozwecke. Im richtigen Beispiel nutze ich MvcContrib
public class ControllerFactory : IControllerFactory
{
    public IController CreateController(RequestContext context, Type controllerType)
    {
        return IoC.Resolve<IController>(controllerType.Name);
    }
}

Es gibt im MVC Framework momentan noch ein paar Ecken wo man nur über Umwege die Objekterzeugung steuern kann. Bei ActionFiltern wird es z.B. etwas kniffliger (geht aber wohl auch - vielleicht ein anderer Blogpost). Dies soll aber mit MVC3 besser werden :)

MvcContrib

Ich nutze dafür aus dem MvcContrib Projekt die WindsorControllerFactory, benötigt werden aus den vielen DLLs lediglich zwei:

image 

Der Einstiegspunkt - Global.asax

In die Global.asax habe ich einfach noch eine "Bootstrapper” Methode eingebaut:

        protected void Application_Start()
        {
            Bootstrapper();

            AreaRegistration.RegisterAllAreas();
            RegisterRoutes(RouteTable.Routes);
        }

        private void Bootstrapper()
        {
            IWindsorContainer container = new WindsorContainer();
            // IFooService with DummyFooService
            container.Register(AllTypes.Pick().FromAssembly(typeof(MvcApplication).Assembly)
                    .WithService.FirstInterface());
            // Controller
            container.RegisterControllers(typeof(HomeController).Assembly);

            // Set the controller factory
            ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(container));
        }

Durch das nutzen der "WindsorControllerFactory” müssen auch alle Controller registriert werden. Dies geschieht in Zeile 16. In Zeile 19 wird dann die ControllerFactory gesetzt.

Fertig. Die richtige Implementation landet beim Aufruf des HomeControllers auch dort wo sie hin soll.

Für andere IoC Container

Phil Haack hat z.B. ein Post mit StructureMap gemacht. In diesem Post wird es mit Spring.NET gemacht.

Wenn es komplexer wird

In diesem Post von Corey Coogan ist ein komplexeres Beispiel erläutert. Jedenfalls hat mir der Blogpost recht viel gebracht und mein Blogpost soll es nur (etwas simpler) wiedergeben.

[ Download Democode ]


blog comments powered by Disqus