Лучшая практика для использования приложения TraceSource
Поэтому у меня есть приложение, в котором я буду использовать трассировку для регистрации активности / ошибок приложения и т. Д. Большая часть информации будет сохраняться в файле журнала, тогда как некоторые ошибки будут также отображаться в средстве просмотра событий. Это приложение будет иметь много классов.
Каков наилучший способ использования TraceSource в этом случае? Должен ли я создать класс TestSource для одноэлементной упаковки или есть ли лучший способ сделать это?
2 ответа
Я в некоторой степени согласен с @Valdis - log4net и NLog являются двумя примерами очень мощных каркасов ведения журналов, которые предлагают большую гибкость и относительно простую в использовании конфигурацию (NLog, вероятно, легче настроить, чем log4net). Тем не менее, я не думаю, что это необходимо, чтобы полностью избежать TraceSource. TraceSource встроен, поэтому вы избегаете лишней зависимости.
Если вы используете TraceSource, я не думаю, что единственный статический объект TraceSource всего приложения - это путь. Я бы порекомендовал использовать больше TraceSources, возможно, даже по одному на класс (это может быть излишним, но это распространенный шаблон при использовании log4net и NLog).
В своем другом вопросе я добавил больше деталей о том, когда использовать в приложении более одного TraceSource.
Вы строго используете встроенную инфраструктуру событий и журналов.net? Я бы посоветовал использовать некоторые из третьих сторон (например, вход в систему из Enterprise Library). они более гибкие, более настраиваемые, и у вас нет таких головных уборов - вы просто пишете:
Logger.Write(...)