HowTo: Dependency Injection in ASP.NET MVC Controllern mit Windsor Castle
Um 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:
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.
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Letzte Kommentare