Лучшая практика для использования приложений TraceSource - PullRequest
1 голос
/ 01 февраля 2011

Итак, у меня есть приложение, в котором я буду использовать трассировку для регистрации активности / ошибок приложения и т. Д. Большая часть информации будет сохраняться в файле журнала, тогда как некоторые ошибки будут также отображаться в средстве просмотра событий. Это приложение будет иметь много классов.
Каков наилучший способ использования TraceSource в этом случае? Должен ли я создать класс TestSource для одноэлементной упаковки или есть ли лучший способ сделать это?

Ответы [ 2 ]

1 голос
/ 02 февраля 2011

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

Если вы используете TraceSource, я не думаю, что единственный статический объект TraceSource всего приложения - это путь.Я бы порекомендовал использовать больше TraceSources, возможно, даже по одному на класс (это может быть излишним, но это обычная практика при использовании log4net и NLog).

Я добавил больше деталей в ответ на ваш другой вопрос оиспользовать более одного TraceSource в приложении.

0 голосов
/ 02 февраля 2011

Строго ли вы используете встроенную инфраструктуру событий и журналов .net?Я бы рекомендовал использовать некоторые из третьих сторон (например, вход в систему из Enterprise Library).они более гибкие, более настраиваемые, и у вас нет таких головных уборов - вы просто пишете:

Logger.Write(...)
...