Ответ 1
Это действительно очень просто; как NLog, так и log4net ожидают, что вы будете использовать однотонные/статические ссылки для получения экземпляров журнала:
private static Logger logger = LogManager.GetCurrentClassLogger();
Это широко рассматривается как анти-шаблон, но даже если у вас нет проблем с ним, он все равно идет против зерна, если вы пытаетесь внедрить инъекцию зависимостей. В случае NLog это даже не интерфейс ILog
или ILogger
, такой как log4net, это фактический класс. Это имеет определенные недостатки, такие как невозможность создания прокси, отложенная загрузка, кэширование и т.д.
Что делает проект Ninject.Extensions.Logging, сначала предоставляет абстрактный ILogger
класс с простыми методами, такими как Info
, Error
и т.д., поэтому вы можете вводить его как зависимость и переключать фреймворк регистрации, если вы хотите:
public class WidgetProvider
{
private readonly ILogger log;
public WidgetProvider(ILogger log)
{
this.log = log;
}
}
Вот как должен работать DI - класс никогда не выходит, чтобы захватить свои собственные зависимости, вместо этого они предоставляются конструктором или вызывающим абонентом, как указано выше. Предполагая, что вы уже интегрировали Ninject в свой проект, это действительно все, что вам нужно сделать, нет дополнительной работы.
Что касается того, что конкретно делает Ninject.Extensions.Logging.NLog2 - он просто обеспечивает реализацию для Ninject.Extensions.Logging на основе NLog2. Базовая библиотека ведения журнала фактически не содержит реализаций ILogger
, вам нужно подключить одну из конкретных библиотек (NLog, NLog2 или log4net), чтобы заставить ее работать.
Если вы переключаете свою библиотеку DI чаще, чем вы переключаете регистраторы, то не беспокойтесь об этом. Но если вы похожи на меня и используете Ninject практически в каждом проекте, то это отличный способ отделить ваш код от какой-либо конкретной библиотеки ведения журнала.