Как использовать TraceSource в разных классах - PullRequest
Новая
       34

Как использовать TraceSource в разных классах

27 голосов
/ 07 декабря 2010

Я недавно изучал документацию по TraceSource . Microsift говорит, что TraceSource - это новый способ, и его следует использовать вместо старого класса Trace. 

// create single TraceSource instance to be used for logging
static TraceSource ts = new TraceSource("TraceTest");

// somewhere in the code
ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found");

Теперь мой вопрос. У вас большой проект с несколькими сборками, где у вас много классов. Скажем, вы хотите отследить определенную функциональность, которая распространяется по классам Очевидная идея заключается в том, что вам нужно создать один конкретный TraceSource.

1) Для работы с Tracesource мне нужно сначала создать экземпляр. Что MS думает о совместном использовании этого экземпляра между различными классами или сборками? Должен ли я создать один фиктивный класс со статическим свойством singleton? Что ты делаешь в этом случае.

2) Зачем мне нужен экземпляр TraceSource? Каждое свойство описано в файле конфигурации. Старая логика, основанная на классе Trace, не требовала какого-либо экземпляра и позволяла работать только со статическими методами.

1 Ответ

35 голосов
/ 08 декабря 2010

* 1.Просто определите TraceSource в каждом классе, где вы хотите его использовать.Вы можете сделать TraceSource статическим, чтобы он был общим для всех экземпляров класса, в котором вы его определяете. Нет необходимости делить экземпляр между всеми классами (типами), которым требуется «тот же» TraceSource.Каждый раз, когда вы объявляете новый экземпляр TraceSource (TraceSource ts = new TraceSource ("somename"); вы получаете новый объект TraceSource, но он ссылается на ту же информацию конфигурации. Таким образом, если вы создаете новый TraceSource в каждом из нескольких классов иВы используете одно и то же имя для каждого, вы получите разные экземпляры TraceSource, но все они будут настроены одинаково. Короче говоря, нет необходимости пытаться делить экземпляры TraceSource между классами. Также нет необходимости создаватьфиктивный класс со статическим синглтоном. См. мои примеры ниже. Я также включил еще несколько ссылок отсюда на SO, которые описывают, как работать с TraceSources. 

//
// In this example, tracing in classes A and B is controlled by the "TraceTest" TraceSource
// in the app.config file.  Tracing in class C is controlled by the "TraceTestTwo"
// TraceSource in the app.config.
//
// In addition to using different TraceSource names, you can also use SourceSwitches 
// (in the app.config).  See some examples of app.config in the
// "turning-tracing-off-via-app-config" link below.
//

public class A
{
  private static readonly TraceSource ts = new TraceSource("TraceTest");

  public void DoSomething()
  {
    ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found");   
  }
}

public class B
{
  //
  //Use the same config info for TraceTest in this class
  //It's ok to use a different instance of TraceSource, but with the same name,
  //in this class, the new instance will be configured based on the params in the
  //app.config file.
  //
  private static readonly TraceSource ts = new TraceSource("TraceTest");

  public void DoSomething()
  {
    ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found");   
  }
}

public class C
{
  //
  //Use a different TraceSource in this class.
  //
  private static readonly TraceSource ts = new TraceSource("TraceTestTwo");

  public void DoSomething()
  {
    ts.TraceEvent(TraceEventType.Warning, 2, "File Test not found");   
  }
}

* 2. Одно преимущество использования нескольких TraceSourcesявляется то, что у вас есть более детальный контроль над вашей трассировкой. Вы можете отслеживать через "TraceTest" на одном уровне (или не на всех) и через "TraceTestTwo" на другом уровне (или, опять же, не на всех). Вы можете отправить каждыйTraceSource в свой собственный TraceListener или отправить все в тот же TraceListener, или смешивать и сочетать.Сравните возможность настраивать конфигурацию отдельных источников TraceSources с ограничением использования только статических методов в классе Trace.Вы можете настроить, куда идет информация «трассировки» (какой TraceListener (ы)) или уровень информации «трассировки», но вы не можете контролировать уровень для класса или функциональной области, как при использовании TraceSources.Наконец, еще одно преимущество нескольких TraceSources - это «бесплатная» контекстная информация, которую вы можете получить в своих выходных данных.По умолчанию (или, возможно, я не помню), TraceListener будет регистрировать имя TraceSource, который зарегистрировал сообщение.Таким образом, вы можете посмотреть на эту строку в своем выводе и получить некоторое представление о классе или функциональной области, откуда она взялась, без необходимости помещать журнал контекстной информации на сайт вызова.В приведенных выше примерах кода выходные данные трассировки из классов A и B будут помечены как «TraceTest», а выходные данные трассировки из класса B будут помечены как «TraceTestTwo».

Просим прощения за ссылку ниже, ноЯ опубликовал довольно хорошую информацию (если я сам так скажу!) О TraceSource и System.Diagnostics в прошлом.

Если вы собираетесь использовать TraceSource, рассмотрите возможность использования библиотеки, упомянутой в этом посте SO, дляформатирование вывода, например, log4net / NLog:

Есть ли в .Net TraceSource / TraceListener framework что-то похожее на средства форматирования log4net?

См. мой ответ в этой записи для получения дополнительной информации об использовании TraceSource и некоторых идей о том, как можно улучшить свой "опыт TraceSource".

Подробнее о TraceSource: Добавление методов трассировки в System.Diagnostics.TraceListener

Дополнительная информация о TraceSource: Пространство имен System.Diagnostics.Debug и другие решения для ведения журналов (log4net, MS EntБиблиотека erprise и т. д.)

Подробнее о TraceSource: Отключение трассировки через app.config

...