Веб-API ASP.NET (самостоятельный хост) + Ninject — привязки по умолчанию

Я конвертирую проект из веб-API WCF в веб-API ASP.NET - спасибо MS :(

POC-код самостоятельного хостинга:

    static void Main(string[] args)
    {
        var kernel = new StandardKernel();

        const string baseAddress = "http://localhost:8080";
        var config = new HttpSelfHostConfiguration(baseAddress);
        config.ServiceResolver.SetResolver(new NinjectServiceLocator(kernel));

        config.Routes.MapHttpRoute("DefaultApi", "api/{controller}/{id}", new {id = RouteParameter.Optional});

        var server = new HttpSelfHostServer(config);
        server.OpenAsync().Wait();
        Console.WriteLine("The server is running....");
        Console.ReadLine();
    }

Я регистрирую Ninject как средство разрешения зависимостей. Для этого я использую CommonServiceLocator.NinjectAdapter для его регистрации:

config.ServiceResolver.SetResolver(new NinjectServiceLocator(kernel));

Насколько я могу судить, это работает, хотя использование SetResolver(object) кажется немного грязным.

Проблема, с которой я столкнулся сейчас, заключается в том, что когда я пытаюсь запустить его, появляется много привязок, которые больше не зарегистрированы (например, IHttpContollerFactory, ILogger и т. д.).

Должен ли я проходить один за другим и перерегистрировать все зависимости «по умолчанию»? Кажется странным, что значения по умолчанию регистрируются в распознавателе зависимостей по умолчанию, но я не вижу быстрого способа перерегистрировать значения по умолчанию, когда установлен новый распознаватель зависимостей. Для чего-то вроде ILogger я даже не могу получить доступ к System.Web.Http.Common.Logging.DiagnosticLogger по умолчанию, чтобы сделать привязку.

Я что-то упускаю?


asp.net-web-api ninject-2 ninject-extensions
person Mike Rowley    schedule 28.03.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Вам не нужно перерегистрировать службы по умолчанию. Если вы вернете null, фреймворк по умолчанию вернется к своему внутреннему контейнеру DI. Кроме того, в последних битах он будет спрашивать только один раз.

person Darrel Miller    schedule 28.03.2012
comment
Возможно, тогда проблема в том, что NinjectServiceLocator выдает исключение, когда сопоставление не найдено. Я буду исследовать дальше. - person Mike Rowley; 29.03.2012
comment
@Discofunk Да, это так. Но фреймворк проглотит это исключение за вас. - person Darrel Miller; 29.03.2012
comment
Я понимаю. При запуске в режиме отладки VS2010 прерывается на исключении, но затем, похоже, проглатывается. - person Mike Rowley; 29.03.2012

arrow_upward
0
arrow_downward

В конце концов, вероятно, лучше просто создать IDependencyResolver для Ninject. Я уверен, что будет «правильный», созданный кем-то, кто лучше разбирается в Ninject, но пока я использую:

public class NinjectDependencyResolverAdapter : IDependencyResolver
{
    private readonly IKernel kernel; 

    public NinjectDependencyResolverAdapter(IKernel kernel)
    {
        this.kernel = kernel;
    }

    #region Implementation of IDependencyResolver

    public object GetService(Type serviceType)
    {
        return kernel.TryGet(serviceType);
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        return kernel.GetAll(serviceType);
    }

    #endregion
}
person Mike Rowley    schedule 29.03.2012
comment
См. github.com/sethwebster/NinjectDependencyResolver для полной реализации. - person Niklas Peter; 14.10.2016