Ответ 1
Есть много похожих вопросов здесь на SO:
- Регистрация лучших практик
- log4net против TraceSource
- Основы ведения журналов Silverlight и/или лучшие практики
- log4net против Nlog
- Какой смысл вырубки фасада?
- С# Logging. Что я должен использовать?
Вы пропустили несколько обычно используемых каркасов журналов. Вот список часто используемых фреймворков, некоторые из которых вы перечислили:
- System.Diagnostics
- log4net
- NLog
- Библиотека предприятия
- Объект Гай
Регистрация абстракций:
System.Diagnostics дополнения:
Другой
Несколько других каркасов журналирования из codeplex (о которых я уже упоминал в SO):
Почему вы можете выбрать один над другим? Это сложный вопрос. Во многом это личное предпочтение. Отчасти это техническое (или особенное) превосходство.
Одним из очевидных недостатков любого каркаса (особенно стороннего) является качество поддержки. Что делать, если у вас есть проблемы с log4net, NLog, Common.Logging и т.д.? Сможете ли вы получить исправления от разработчиков этих фреймворков? Это может быть не очень важно, так как исходный код доступен для этих платформ. Однако вы можете предпочесть НЕ "наследовать" исходное дерево только для того, чтобы исправить или добавить расширение. Я скажу, что фреймворки настолько расширяемы, что многие улучшения могут быть добавлены через обычные точки расширения.
Если вы прочтете ссылки, которые я разместил выше, я думаю, что будет справедливо сказать, основываясь исключительно на количестве благоприятных упоминаний, что log4net будет явным "победителем". Это будет упоминаться чаще как исторический фаворит и то, что многие люди будут использовать в будущем.
У NLog есть свои сторонники, просто у него, похоже, нет проникновения или понимания на высшем уровне, как у log4net, хотя они очень похожи. Возможности NLog очень похожи на log4net, и у него есть дополнительное преимущество, поскольку он недавно прошел значительный цикл разработки.
Корпоративная библиотека часто рекламируется как хороший выбор, но почти так же часто рекламируется как ужасный выбор. Может быть, какая-то его негативная репутация, возможно, не очень хорошие ранние версии? Может, сейчас лучше?
System.Diagnostics часто рекомендуется в качестве разумного выбора, по крайней мере, с тремя сильными преимуществами: отсутствие сторонней зависимости, многие компоненты Microsoft снабжены System.Diagnostics, его легко расширить (предположительно, для добавления некоторых функций, которые уже присутствуют "бесплатно"). в рамках, таких как log4net и NLog?). Если вы используете System.Diagnostics, я думаю, что консенсус будет (как и моя рекомендация) использовать объекты TraceSource, а не Trace.WriteLine/Debug.WriteLine.
Также обратите внимание, что System.Diagnostics и WCF хорошо работают вместе. Трафик сообщений WCF может регистрироваться с помощью System.Diagnostics, и WCF также будет распространять информацию о действиях System.Diagnostics(System.Diagnostics.CorrelationManager.ActivityId) через пограничные вызовы службы WCF.
Я не уверен, что log4net должен продолжать сохранять свой наиболее предпочтительный статус. Как уже было отмечено здесь, в SO, log4net, похоже, в последнее время не подвергается большой разработке (обратите внимание, что я думаю, что "log4net мертв" - это преувеличение), в то время как NLog 2.0 в настоящее время находится в бета-версии, а окончательный выпуск ожидается в Q1. 2011 (обновление: NLog 2.0 был выпущен 17 июля 2011 года). Делает ли это NLog явно лучшим выбором, чем log4net? Я не знаю, но я думаю, что, условно говоря, NLog должен получать как минимум одинаковое внимание при выборе между этими двумя и, вероятно, должен быть предполагаемым фаворитом для новой разработки, по крайней мере, до тех пор, пока разработка log4net не покажет больше признаков жизни.
log4net и NLog предлагают очень гибкие параметры конфигурации. Они позволяют вам иметь очень тонкую гранулярность в определении ваших операторов регистрации (по "стандартной" схеме определения регистратора для каждого типа). Они также позволяют легко расширять библиотеки, позволяя вам создавать свои собственные объекты "назначения журналирования" (log4net Appenders и NLog Targets) и объекты "форматирования" (конвертеры шаблонов log4net и NLog LayoutRenderers).
Помимо выбора структуры ведения журнала, некоторые (многие?) Выступают за изоляцию кода вашего приложения от жесткой зависимости от конкретной среды ведения журнала с помощью уровня абстракции. Это может принять форму вашего собственного интерфейса ILogger, который вы реализуете, возможно, поверх существующего фреймворка. В будущем вы могли бы изменить каркас, внедрив свой ILogger в другом каркасе. Или вы можете использовать DI/IoC для добавления "ILogger" в ваш код. Многие инфраструктуры DI/IoC предоставляют встроенную абстракцию ILogger, которую можно настроить на использование log4net, NLog или Enterprise Library или вы можете написать собственную реализацию ILogger и внедрить ее). Кому какое дело до реализации? Другой способ изолировать ваш код от жесткой зависимости от конкретной среды ведения журналов - это использовать существующую структуру абстракции ведения журнала, такую как Common.Logging или SLF. Преимущество заключается в том, что, опять же, ваше приложение не зависит от конкретной структуры ведения журналов. Однако некоторые скажут, что вы только что обменяли одну зависимость (на каркасе логирования) на другую (каркас абстракции логирования).
Еще две заметки о регистрации абстракции:
-
Хорошая абстракция журналирования должна позволять вам захватывать выходные данные из разных каркасов журналирования в одном выходном файле. Common.Logging называет это "мостом". Допустим, вы написали приложение с использованием Common.Logging, поддержанное NLog. Теперь скажите, что вы используете стороннюю библиотеку классов, которая написана с использованием log4net напрямую. С помощью системы мостов вы можете захватить выходные данные log4net (через настраиваемое приложение) и перенаправить их через Common.Logging, чтобы выходные данные журналов библиотеки сторонних классов можно было просматривать в контексте выходных данных журналов вашего приложения.
-
Использование абстракции журналирования также позволяет вам тестировать каркасы журналов во время разработки. Вы могли бы начать думать, что log4net - это тот путь, но вы хотите оставить себя открытым для попытки NLog. Используя абстракцию логирования, относительно легко переключаться между ними. В конечном счете, вы можете выбрать, какой каркас журналирования, но в то же время вы смогли написать множество кода, который никак не зависит от конкретной каркаса журналирования.
Другая причина, по которой вы можете выбрать один фреймворк вместо другого, - это среда, в которой вы работаете. Если вы уже используете часть Enterprise Library, этого может быть достаточно, чтобы подтолкнуть вас к использованию ведения журнала Enterprise Library.
Что делать, если вы разрабатываете в Silverlight? Вы можете использовать что-то вроде Clog - часть кальция. Вы также можете использовать NLog 2.0, который совместим с Silverlight и WP7.
Аддоны System.Diagnostics(Ukadc.Diagnostics, Essential.Diagnostics). Это не каркасы журналирования как таковые. Скорее, они представляют собой наборы полезных объектов и точек расширения, которые можно использовать с существующей платформой System.Diagnostics. На мой взгляд, одна из лучших вещей, которую добавляет каждый из этих дополнений, - это возможность форматировать выходные данные журналов, подобно тому, как вы можете форматировать их с помощью log4net и NLog. Я не использовал Essential.Diagnostics, но я экспериментировал с Ukadc.Diagnostics и думаю, что это действительно круто. Даже легко написать свои собственные "токены форматирования".
Я не знаю, полностью ли это ответило на ваш вопрос (который в любом случае довольно широк), но я думаю, что здесь есть много пищи для размышлений.