Rolf b: Kein parameterloser Konstruktor

Beitrag lesen

Moin,

ich war das WE verreist, drum schreibe ich jetzt erst wieder.

Es gibt nur ein Unity, und es weiß überhaupt nichts von MVC oder API oder WebForms oder sonstwas. Es weiß nur was von Dependencies und kann sie automatisch einspritzen.

MVC und Web API wissen dagegen was von Controllern und haben Discovery-Techniken und Controller-Factories, um das "Convention before Configuration" Prinzip umzusetzen. Irgendein Döspaddel bei den ASP.NET Architekten hat es aber versäumt, hier von Anfang an auf Einheitlichkeit zu achten - oder es gab technische Gründe, warum es nicht anders ging - und deshalb sind es getrennte Factories, die man auch getrennt für Unity aufpimpen muss.

Das kann man mit fertigen Paketen tun, oder man kann es auch selbst programmieren.

Für MVC Controller brauchst Du eine Implementierung von IDependencyResolver, die Du bei DependencyController.Current hinterlegst. Diesess Interface befindet sich im System.Web.Mcv Namespace. Ein MVC-to-Unity Adapter muss sich hier einklinken, und darüber entweder einen IControllerActivator oder eine IControllerFactory bereitstellen. Der IControllerActivator ist die bevorzugte Lösung. Das MVC5-Unity Paket dürfte einen IControllerActivator enthalten. Details dazu kannst Du googeln :)

Für das Web.API brauchst Du auch eine IDependencyResolver Implementierung. Aber - wie gesagt - es ist eine andere. Es ist ein ANDERES Interface mit gleichem Namen, im System.Web.Http.Dependencies Namespace, und Du hinterlegst die Implementierung in GlobalConfiguration.Configuration.DependencyResolver.

Wenn Du MVC und WebAPI gemeinsam verwenden willst, musst Du beide Dependency-Resolver bereitstellen und beide auf die ihnen genehme Art registrieren. Wenn es dafür kein fertiges Nuget-Paket gibt, musst Du es von Hand mischen. Am Ende hast Du dann drei Bausteine: Unity selbst, den MVC-to-Unify Adapter und den WebAPI-to-Unity Adapter.

Rolf