Дефолтный глобальный логгер?

@kotelok · Регистрация: 08.08.2014

Студворк — интернет-сервис помощи студентам

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public sealed class Some
{
    private readonly ILogger? _logger;
 
    public Some(<много аргументов для инициализации состояния объекта>)
    {
        _logger = <попытаться откуда-то получить экземпляр логгера>;
    }
 
    public object ProcData(object obj)
    {
        _logger?.LogInformation("start proc data");
 
        return obj;
    }
 
    ..
}

Как вообще в подобных ситуациях получать экземпляр логгера?

Через параметры конструктора передавать неудобно, т.к. приходится этот 'ILogger' (или 'ILoggerFactory') через весь код всех классов таскать.

Запрашивать экземпляр через DI тоже не вариант, т.к. просто это маленький вспомогательный класс, который напрямую создаётся клиентским кодом с передачей кучки аргументов напрямую, используется и сразу забывается.

Использовать singleton-фабрику, описанную в статическом классе в той же сборке? И при использовании в других сборках, не забывать выполнять явную инициализацию этой фабрики?

Или всё проще, и я просто не нашёл какой-то "глобальный дефолтный ILogger всего процесса"?

@Wolfdp · 29.07.2025, 21:24

Подрубаешь Microsoft.Extensions.Hosting, там всё приложение строится вокруг IHost, который внутри себя содержит всё шо надо: ioc-контейнер, логер, конфигурации. Далее просто в ЛЮБОМ месте добавляешь в конструктор ILogger, да и вообще любой IServiceName и тебе прокинет нужное без лишних телодвижений. Для относительно крупных проектов это единственно верный подход.

Если приложение состоит из двух-трёх сервисов, то фигачим в static в любом виде и забиваем.

@kotelok · 29.07.2025, 21:41 **[ТС]**

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

А как вообще, при таком вот сценарии, экземпляр через DI-контейнер запрашивать?

C#
1
2
3
4
5
6
    ..
 
    var some = new Some(a, b, c, ratio, logger);
    var result = some.Calc(rawData, ProcMethod.NewGen);
 
    ..

Ну и даже если очистить все конструкторы, оставив там только то, что через DI запрашивается, то это придётся для многих таких маленьких сервисов/хелперов ещё и фабрики для каждого делать, и инжектить их во все нужные конструкторы, т.к. экземпляров может потребоваться далеко не один в процессе работы какого-нибудь метода.

@Wolfdp · 29.07.2025, 21:57

Общий подход такой:

- всё что требует явного new уходит в фабрику. Например для нового TCP подключения мы создаем свою TcpSession на основе TcpClient. Значит добавляем TcpSessionFactory, которая в конструкторе принимает все логеры, опции и прочие общие необходимые сервисы для каждой сессии. Выглядит этот как-то так

C#
1
2
3
4
5
6
7
8
class TcpSessionFactory(ILogger logger, IOptions<SessionOptions> options, IHandlerFactory handlerFactory)
{
    public TcpSession Create(TcpClient client)
    {
         var handler = handlerFactory.Init(TcpClient);
         return new TcpSession(clietn, handler, logger, options);
    }
}

В некоторых случаях нужно ещё оперировать Scope или прокидывать ServiceProvider в фабрику, но это для тех кто хотя бы в базу погрузился.

- всё остальное регистрируется в ServiceProvider где-то на старте приложения. Соответсвенно ваш логер, да собственно и всё остальное просто прокидывается конструктор. Дело в том что вам не нужно самому писать new и километровый список. Плюс вам не нужно тянуть с самого верха в параметрах какой-то класс, чтобы прокинуть в самый низ. Это пипец как разгружает код, когда в параметрах конструктора только то, что будет использовать в классе, а не какие-то "попутчики".

......

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

@kotelok · 29.07.2025, 22:24 **[ТС]**

Сообщение от Wolfdp

приложение

Консольная утилита, которая запускается, получает на вход "сырые данные + конфиги", выполняет сложную последовательную обработку и завершается, оставляя после себя обработанные данные и один гигантский лог-файл.

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

@Wolfdp · 29.07.2025, 22:48

Сообщение от kotelok

Консольная утилита

Дык утилиты тоже разные по объему кода бывают. Есть на пару страниц, есть на пару гигабайт... Технически фиолетово где применять, но могут начать задавать вопросы "а чего это нам подрубать либ на 300+МБ!?"

Сообщение от kotelok

И есть требование по очень детализированному логированию

Вроде как есть либы, которые умеют всё зареганное проксировать и логировать вызов каждого метода. Я бы копнул эту тему, возможно срубит часть рутины по прописыванию "вызов метода А с параметрами 1, 2, 3". Но это чисто мои догадки, сам не разу не ресёчил данный подход.

Насчёт использования DI: я так понимаю вам в каждом классе кода по сути нужно иметь доступ к логеру, причём к единому, без всяких скопов и прочих настроек? Тут конечно напрашивается забить и пихнуть всё в статику. Если приложение уже написанное и нужно только добавить логирование, и дальнейшего развития тулзы не предвидится -- это резкие аргументы не усложнять задачу и сделать "лишь бы работало".

@Usaga · 30.07.2025, 03:33

Сообщение от kotelok

Запрашивать экземпляр через DI тоже не вариант, т.к. просто это маленький вспомогательный класс, который напрямую создаётся клиентским кодом с передачей кучки аргументов напрямую, используется и сразу забывается.

Не понимаю, как это мешает использовать DI. DI тут самое то решение.

@kotelok · 30.07.2025, 05:03 **[ТС]**

Сообщение от Wolfdp

могут начать задавать вопросы

Тут, скорее, я сам себе задаю вопрос - а чего я тут DI наворотил, и фабрику к каждому микро-классу, и вместо обычного 'new' сначала инжектю фабрики в конструктор, сохраняю их в приватные поля, потом через них инстанциирую объекты. Не слишком ли излишне под задачу "просто расшарить один общий логгер на все классы библиотеки".

@Usaga · 30.07.2025, 05:21

Сообщение от kotelok

Не слишком ли излишне под задачу "просто расшарить один общий логгер на все классы библиотеки".

Излишне. Просто инжектируй логер и сохраняй в поле. А потом скармливай кому надо.

@Wolfdp · 30.07.2025, 07:09

kotelok,
лучше вас никто не ответит, излишне или нет. Весь проект перед глазами только у вас. Слепо верить рекомендациям не самая светлая мысль, поэтому ваши сомнения это нормально.

Я исхожу из своего скромного опыта, в первую очередь как бывший бэкенд-разработчик. Практически все проекты строились с использованием ioc-контейнера, и нужно было пробрасывать две вещи практически в каждый создаваемый класс: логер и конфиги. Конкретно с ними ни разу не возникало проблем. Вынос создания объектов в фабрику, а не через new обосновывался тем что постоянно требовалось передавать много различных объектов, которые не шибко хотелось держать в местах где просто нужно пнуть Create, плюс это более реюзабельно. Технически можно обойтись и без фабрики, местами даже нужно.

Был опыт написания без всяких DI-либ, как положительный (на малом проекте), так и отрицательный (на условно среднем по объему, но с кучей модулей, и переиспользованием чужого кода).

Новые блоги и статьи Все статьи Все блоги /
http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Первый деплой lagorue 16.01.2026 Не спеша развернул своё 1ое приложение в kubernetes. А дальше мне интересно создать 1фронтэнд приложения и 2 бэкэнд приложения развернуть 2 деплоя в кубере получится 2 сервиса и что-бы они. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа, решает её и находит: токи, напряжения и их 1 и 2 производные при t = 0;. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .
Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .

@Wolfdp 3790 / 1767 / 371 Регистрация: 15.06.2012 Сообщений: 6,543 Записей в блоге: 3
	29.07.2025, 21:24
	Подрубаешь Microsoft.Extensions.Hosting, там всё приложение строится вокруг IHost, который внутри себя содержит всё шо надо: ioc-контейнер, логер, конфигурации. Далее просто в ЛЮБОМ месте добавляешь в конструктор ILogger, да и вообще любой IServiceName и тебе прокинет нужное без лишних телодвижений. Для относительно крупных проектов это единственно верный подход. Если приложение состоит из двух-трёх сервисов, то фигачим в static в любом виде и забиваем. 1

@Wolfdp 3790 / 1767 / 371 Регистрация: 15.06.2012 Сообщений: 6,543 Записей в блоге: 3
	30.07.2025, 07:09
	kotelok, лучше вас никто не ответит, излишне или нет. Весь проект перед глазами только у вас. Слепо верить рекомендациям не самая светлая мысль, поэтому ваши сомнения это нормально. Я исхожу из своего скромного опыта, в первую очередь как бывший бэкенд-разработчик. Практически все проекты строились с использованием ioc-контейнера, и нужно было пробрасывать две вещи практически в каждый создаваемый класс: логер и конфиги. Конкретно с ними ни разу не возникало проблем. Вынос создания объектов в фабрику, а не через new обосновывался тем что постоянно требовалось передавать много различных объектов, которые не шибко хотелось держать в местах где просто нужно пнуть Create, плюс это более реюзабельно. Технически можно обойтись и без фабрики, местами даже нужно. Был опыт написания без всяких DI-либ, как положительный (на малом проекте), так и отрицательный (на условно среднем по объему, но с кучей модулей, и переиспользованием чужого кода). 1