ASP.NET Web API (Self Host) + Ninject - привязки по умолчанию - PullRequest
1 голос
/ 29 марта 2012

Я конвертирую проект из веб-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 для привязки.

Я что-то упустил?

Ответы [ 2 ]

2 голосов
/ 29 марта 2012

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

0 голосов
/ 29 марта 2012

В конце, вероятно, лучше просто создать 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
}
...