Вход в библиотеку С#

Ответ 1

Красота использования log4net заключается в том, что ваша библиотека не должна указывать, где что-то регистрируется. Назначение (журнальные приставки) сообщений журнала определяется конфигурацией, которая задается приложением (обычно в файле конфигурации).

Итак, используйте log4net, следуя рекомендуемым шаблонам (уникальный "регистратор" для каждого класса) и сообщите своим пользователям, что ваша библиотека использует log4net. Любые сообщения журнала, которые генерирует ваш код библиотеки, будут маршрутизироваться в соответствии с конфигурацией потребителей (файл, база данных, консоль, трассировка и т.д.).

EDIT: хороший короткий праймер в log4net, который объясняет основные понятия.

Ответ 2

Я использую log4net в своей собственной библиотеке, но я бы этого не сделал, если бы моя библиотека использовалась другими (то есть вне моей организации). В этом случае я бы использовал интерфейс для ведения журнала, обеспечил реализацию по умолчанию на основе log4net в отдельной сборке и так или иначе использовал, чтобы пользователи библиотеки могли внедрить свою собственную реализацию.

Сказав это: мне очень нравится log4net и не буду использовать ничего другого, но я думаю, что это неправильно, чтобы заставить других использовать структуру ведения журнала по вашему выбору.

Изменить:

• Я бы также не счел хорошей практикой наличие журнала библиотеки в файл по умолчанию. Пользователи вашей библиотеки должны иметь возможность определять, где находятся сообщения журналов.
• Я также предоставил бы реализацию "без операции", которая может быть использована, если вообще не требуется регистрация. Возможно, это должно быть поведение по умолчанию, не требующее каких-либо дополнительных сборок или шагов для реализации.

Ответ 3

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

например, вы можете попробовать this или просто написать свой собственный.

Ответ 4

log4net - это просто сторонняя библиотека, это не самая лучшая практика, которую вы должны использовать в качестве своей библиотеки регистрации при использовании С#. Мой совет всегда будет сохранять журнал где-нибудь (чаще всего это текстовый файл). Однако есть также журнал событий (требуется небольшая дополнительная настройка).

Я стараюсь использовать NLog, который я считаю очень простым в использовании и простым в настройке. Что касается входа в ваши библиотеки классов, это действительно так, что когда-либо приближалось к вам, лучше всего подходит для вашего приложения. Некоторые люди создавали бы 1 регистратор и передавали бы его в классы, другие создавали отдельный журнал на класс loggable. Я стараюсь создать статический логгер для каждого класса, и он отлично работает.

Ответ 5

Это зависит от того, что вы хотите сделать.

Вы хотите иметь механизм регистрации для чистых технических элементов, которые вы можете включать/выключать с различной многословием (для вспомогательных действий)? Или вы хотите регистрировать больше связанных с бизнесом материалов, предназначенных для чтения пользователями вашей библиотеки?

Сначала вы должны ответить на эти вопросы, затем вы можете решить, что делать в журнале, где его хранить и как его форматировать...

В любом случае log4net - это хорошая, зрелая и стабильная структура ведения журнала для всех этих целей. И для входа в скользящий файл - обычная практика (но далеко не единственный вариант...).

Отношения Томас

Ответ 6

Какие пользователи используют для ведения журнала?
Это вопрос, на который вам нужно ответить, чтобы определить правильную структуру.
Log4net является мощным и относительно простым из моего pov. Вы также можете использовать его для входа в streamwriter, если ничего не указано.

Ответ 7

Я использую SmartInspect.

Самое приятное в этой программе - это то, что вы можете фильтровать журналы в приложении для просмотра, что на практике невероятно полезно.

Для записи я никак не связан с SmartInspect.

Ответ 8

По моему мнению, никогда не помешает обернуть логи в свой маленький адаптер, например, чтобы потом легко убрать логи с производства. Я создал для этого небольшую оболочку регистрации, его API выглядит так:

Log.d("I'm a log message");
Log.w("I'm a warning with parmas", "param 1", 2, "..");
Log.e("I'm an error");
Log.e(new Exception("I'm an exception"));
AssertV2.IsTrue(1 + 1 == 3, "This assertion will fail");

Смотрите https://github.com/cs-util-com/cscore#logging для большего количества примеров

Вы можете войти в консоль, файл, Unity и можете легко добавлять более сложные цели ведения журналов, такие как, например, Serilog

Дайте мне знать, если у вас есть предложения или другие отзывы, я хочу сохранить их как можно меньше, но хочу узнать о случаях использования, которые они еще не охватили 💚

Ответ 9

Я бы не хотел вводить зависимость от сторонней библиотеки, такой как log4net, в библиотеку классов общего назначения: я бы предпочел, чтобы вызывающая сторона решала, как вести запись в журнал. Что если пользователь библиотеки уже использует другую структуру ведения журнала?

Некоторые альтернативы:

• В случае ошибок, сгенерируйте Exception или разрешите ему распространяться, и позвольте вызывающему обработать его и выполнить любую регистрацию.

• Для предупреждений (например, Исключение, которое вы обрабатываете в библиотеке), вы можете подумать о том, чтобы вызвать событие, которое может обработать вызывающий, если он захочет зарегистрировать его. Например, вы можете вызвать событие Error которое принимает System.IO.ErrorEventArgs (или аналогичные пользовательские EventArgs) с подробной информацией об ошибке.

• Если вы чувствуете, что библиотека нуждается в большем количестве инструментов, вы можете вызывать больше событий в стратегических точках вашей библиотеки, которые вызывающий может обработать для ведения журнала.

• Вы можете сделать что-то похожее на вход в AWS SDK для .NET, то есть поддерживать несколько каркасов журналирования, но загружать сторонние каркасы, используя отражение, чтобы не создавать зависимости. Лично мне это не нравится, но это правильный подход, особенно если ваша библиотека достаточно велика, чтобы оправдать подробное инструментирование.