В readme на странице библиотеки для интеграции Serilog в .NET Core serilog-aspnetcore такой код присутствует почти в самом начале в разделе Instructions. И когда программист знакомится с Serilog и заходит на эту страницу, то он расценивает это как рекомендацию. Разработчики сразу со страницы readme библиотеки практически заявляют: вот инструкция — делай так:
используй Log.Logger
интегрируй Serilog в подсистему логирования .NET Core.
И программисты так и будут делать. Они будут копипастить этот код. И будут привыкать так делать из проекта в проект. Если будет опытный наставник вроде Вас — хорошо. Но далеко не всем так везёт.
Зачем же вы в тестах используете оверлоад, который работает с Log.Logger, когда есть оверлоад, который примет ваш логгер снаружи, тем самым сняв все проблемы со множественными логгерами (и жизненным циклом)?
Неочевидно, что для тестов мне следует использовать какой-то специальный оверлоад. При использовании других логгеров в .NET Core не приходится использовать какие-то особые оверлоады. Там одинаково работает как в тестах, так и вне их.
Такой оверлоад всё равно приводит к ситуации с двумя логгерами: один в Log.Logger, а другой в подсистеме логирования .NET Core (в контексте использования примера от разработчиков Serilog).
прикладному разработчику вообще не обязательно давать доступ к серилогу
К Log.Logger всегда есть доступ — на то он и глобальный логгер. Если Я правильно понял, и речь идёт про обёртку над Serilog, то это напоминает работу с полуфабрикатом. Он такой неудобный/непонятный, что приходится делать обёртку, чтобы ограничить другим разработчикам доступ, и чтобы они там не натворили чего лишнего. Или написать анализатор кода с той же целью (как Вы предложили).
И про нее можно сказать банальное «просто не делайте так»
Мне кажется, такое обычно не работает. Я много раз видел, кода различные библиотеки (или даже стандартные классы) используют совсем не так, как это нужно делать просто потому, что «так проще», «и так работает», «я просто скопипастил из интернета».
В readme на странице библиотеки для интеграции Serilog в .NET Core serilog-aspnetcore такой код присутствует почти в самом начале в разделе Instructions. И когда программист знакомится с Serilog и заходит на эту страницу, то он расценивает это как рекомендацию. Разработчики сразу со страницы readme библиотеки практически заявляют: вот инструкция — делай так:
И программисты так и будут делать. Они будут копипастить этот код. И будут привыкать так делать из проекта в проект. Если будет опытный наставник вроде Вас — хорошо. Но далеко не всем так везёт.
К Log.Logger всегда есть доступ — на то он и глобальный логгер. Если Я правильно понял, и речь идёт про обёртку над Serilog, то это напоминает работу с полуфабрикатом. Он такой неудобный/непонятный, что приходится делать обёртку, чтобы ограничить другим разработчикам доступ, и чтобы они там не натворили чего лишнего. Или написать анализатор кода с той же целью (как Вы предложили).
Да, сделать можно — согласен. Но в подсистеме логирования .NET Core так не делается. И Serilog внедряет туда только один ILogger объект.
Мне кажется, такое обычно не работает. Я много раз видел, кода различные библиотеки (или даже стандартные классы) используют совсем не так, как это нужно делать просто потому, что «так проще», «и так работает», «я просто скопипастил из интернета».