Как НЕ использовать ядро ​​Ninject в качестве локатора ресурсов - PullRequest
Новая
       16

Как НЕ использовать ядро ​​Ninject в качестве локатора ресурсов

4 голосов
/ 25 января 2012

Я довольно плохо знаком с Ninject и DI в целом.Я использую NHibernate в качестве своего ORM для своего приложения MVC и был вполне доволен моими результатами.То есть, пока я не обновил Ninject 2.1 до 2.2.

Теперь я получаю ошибки в своем классе NinjectWebsiteApplication из-за использования ядра Ninject в качестве локатора ресурсов.

Пример: 

 void NinjectWebsiteApplication_BeginRequest(object sender, System.EventArgs e)
 {
     ILogger logger = Kernel.Get<ILogger>();
     logger.Debug(“**********REQUEST BEGIN****************”);
     logger.Debug(“**** URL = ” + Request.Url.AbsolutePath);
 }

Пример 2: 

protected override void OnApplicationStarted()
{
    var bootstrapper = Kernel.Get<Bootstrapper>();
    bootstrapper.RegisterAllAreas();
    AreaRegistration.RegisterAllAreas();
    ......
    (More stuff here, like AutoMapper mappings, etc.)
    ......
}

* Класс Bootstrapper - это класс, который я создал, где я регистрирую свои маршруты, глобальные фильтры и т. Д.

В обоих приведенных выше примерах, Я получаю предупреждение о функциях Kernel.Get(), которое гласит:

'Ninject.Web.Mvc.NinjectHttpApplication.Kernel' устарел: «Не используйте Ninject в качестве локатора служб»

После нескольких поисков по этому вопросу, общее согласие заключается в том, что это правда.

Я пытаюсь обойти это, но я немного растерялся относительно того, что делать.

Я загрузил новейший пакет Ninject.Web.Mvc NuGet, который создает статический класс NinjectMVC3 в папке App_Start.Я вижу, что они ссылаются на Microsoft.Web.Infrastructure.DynamicModuleHelper, но я не понимаю, где это вписывается в то, что я пытаюсь сделать.

Если у кого-нибудь есть какие-то подсказки, которые помогут мне исправить мой маленький беспорядок,Я был бы очень признателен!

1 Ответ

2 голосов
/ 25 января 2012

Первый способ заключается не в использовании события NinjectWebsiteApplication_BeginRequest, а в создании пользовательского фильтра глобальных действий: 

public class LogActionFilterAttribute : ActionFilterAttribute
{
    private readonly ILogger _logger;
    public LogActionFilterAttribute(ILogger logger)
    {
        _logger = logger;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        _logger.Debug("**********REQUEST BEGIN****************");
        _logger.Debug("**** URL = " + filterContext.HttpContext.Request.Url.AbsolutePath);
    }
}

, а затем в вашем App_Start/NinjectMVC3.cs: 

/// <summary>
/// Load your modules or register your services here!
/// </summary>
/// <param name="kernel">The kernel.</param>
private static void RegisterServices(IKernel kernel)
{
    kernel.Bind<ILogger>().To<Logger>();
    kernel.BindFilter<LogActionFilterAttribute>(FilterScope.Global, 1);
}

Не забудьте добавить using Ninject.Web.Mvc.FilterBindingSyntax;, чтобы вывести метод расширения BindFilter<> в область действия.

И поскольку у вас есть доступ к ядру внутри метода RegisterServices, который происходит при запуске приложения, вы можете подключить все остальное, включая загрузчик, ...

Что касается вашего Global.asax, вы больше не используете в нем какие-либо специфические вещи Ninject. Вы не должны происходить от NinjectApplication.

Инфраструктура WebActivator позволяет использовать отдельный метод инициализации.

...