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
Hi, ich bin Robert Mühsig und bin Webentwickler und beschäftige mich mit Web-Frameworks auf dem Microsoft Web Stack und scheue mich auch nicht vor Javascript. Der Blog begann als "Problemsammelstelle und Lösungshilfe" und seitdem schreibe ich hier alles auf. Seit 2008 bin ich Microsoft MVP für ASP.NET. Treffen kann man mich online via Twitter (@robert0muehsig) oder hier.
Letzte Kommentare