то обсуждаете!
ILogger<T> - это просто пик всратого API-дизайна
Во-первых хорошо наследили в самом начале netcore, когда в первой версии сделали независимым от всего, во второй версии намертво приколотили к M.E.DI, в третьей - вернули частично взад через костыли, так что сиди разбирайся теперь с провайдерами фабрик логгеров
Во-вторых - надергали отовсюду теоретических фич, а ля EventId, BeginScope, ForContext<T> - а как оно все вместе должно сочетаться не подумали
В-третьих - накрутили байтоебских оптимизаций красного уровня по кривой Ш, так что всё ещё обмазано сорс-генераторами с анализаторами
А что простому работяге надо? Что б был рут-логгер - этого нет, что б был контекст логгера - так у нас типа для этого T в ILogger<T>, а то что для нормальной работы с этим нужна вложенность, что б логгер B порожденный в контексте логгера A, мог бы себя не только B обозначит, но и A.B - то этого нету, молись чтобы BeginScope нормально отработал для этого сценария
ну ты зря так, 1. хз что тебя запутало, есть 2 точки расширения ILoggerFactory, которая создаёт ILogger, её можно подменить. но тогда весь мс код логирования, вместе с конфигурацией пойдёт лесом (привет серилог). Можно зарегать ILoggingProvider и тогда оркестрацией логов будет заниматься MS.Logging, а твой код провайдер будет отвечаться за маленький кусочек (например за логирование в консоль) 2. EventId — идентификатор сообщения, BeginScope — тоже понятно (скоуп, которые могут быть вложенными, работает на AsyncLocal), ForContext — это вообще из серилога и не относится к ms.logging 3. логеры сделаны плоскими и через генерики, потому что предполагается их использование через DI, а там нет вложенности и есть типы
Обсуждают сегодня