WebApi, Autofac, System.Web.Http.Filters.ActionFilterAttribute Instance Per Request
Мы давно используем Autofac в нашем приложении (сейчас MVC 4), у нас есть десятки атрибутов на базовом контроллере, от которых все наследуется, и все работает нормально, поэтому, когда запрос начинается, наш сервис создается и затем доступен через все атрибуты и действия контроллера.
Сейчас мы смотрим на WebApi и создали наш контроллер WebApi и создали атрибут на базовом контроллере, используя ActionFilterAttribute из пространства имен HTTP. Однако проблема начинается здесь, когда служба, внедренная в свойство атрибута, не совпадает с экземпляром в ApiController. Глядя на ссылку ниже, это кажется известнымASP.NET Web API и зависимости в области запроса
Однако решение здесь не является идеальным, так как мы не хотим, чтобы наши контроллеры знали о внедрении зависимостей, мы просто хотим использовать сервис, который мы внедряем в свойство, и знаем, что это один экземпляр на запрос.
Мы называем это:
builder.RegisterWebApiFilterProvider(GlobalConfiguration.Configuration);
А также
GlobalConfiguration.Configuration.DependencyResolver = new AutofacWebApiDependencyResolver(container);
Наши классы в настоящее время зарегистрированы в Autofac как InstancePerLifetimeScope, и мы хотим, чтобы каждый запрос мог работать с MvcControllers и ApiControllers.
Это возможно?
РЕДАКТИРОВАТЬ:
Таким образом, в основном эта строка возвращает правильный сервис для запроса (то есть тот же экземпляр, что и на ApiController)
var service = actionContext.Request.GetDependencyScope().GetService(typeof(IOurService);
Но экземпляр внедрения свойства в ActionFilterAttribute не совпадает, и если я изменяю регистрацию Autofac на InstancePerApiRequest, я получаю следующую ошибку:
«Из области, в которой был запрошен экземпляр, не видна область с тегом, совпадающим с« AutofacWebRequest ». Обычно это указывает на то, что компонент, зарегистрированный как запрос на HTTP, запрашивается компонентом SingleInstance () (или аналогичным сценарием). При веб-интеграции всегда запрашивайте зависимости из DependencyResolver.Current или ILifetimeScopeProvider.RequestLifetime, а не из самого контейнера ».