Это может быть связано с тем, что Pass ILogger или ILoggerFactory являются конструкторами в AspNet Core? , однако это особенно касается Библиотечного дизайна, а не того, как фактическое приложение, использующее эти библиотеки, реализует его ведение журнала.
Я пишу библиотеку.net Standard 2.0, которая будет установлена через Nuget, и чтобы пользователи, использующие эту библиотеку, могли получить некоторую информацию об отладке, я в зависимости от Microsoft.Extensions.Logging.Abstractions позволяет стандартизованному Logger быть введенным.
Тем не менее, я вижу несколько интерфейсов, а пример кода в Интернете иногда использует ILoggerFactory
и создает регистратор в ctor класса. Там также ILoggerProvider
который выглядит как версия Factory только для чтения, но реализации могут или не могут реализовывать оба интерфейса, поэтому мне нужно будет выбрать. (Завод кажется более распространенным, чем поставщик).
Некоторый код, который я видел, использует неосновный интерфейс ILogger
и может даже использовать один экземпляр одного регистратора, а некоторые принимают ILogger<T>
в своем ctor и ожидают, что контейнер DI поддерживает открытые типы общего типа или явную регистрацию каждого и каждая ILogger<T>
используемая моей библиотекой.
Прямо сейчас, я думаю, что ILogger<T>
- правильный подход, и, возможно, ctor, который не принимает этот аргумент и просто передает Null Logger. Таким образом, если регистрация не требуется, ни один не используется. Тем не менее, некоторые контейнеры DI выбирают самый большой ctor и, таким образом, терпят неудачу в любом случае.
Мне любопытно, что я должен делать здесь, чтобы создать наименьшее количество головной боли для пользователей, при этом при необходимости поддерживая надлежащую регистрацию.