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.