Когда мне нужно больше, чем один трасес в коде?

Question

Если одно приложение записывает все данные о активности в одном файле журнала, есть ли использование более одного Tracesource? Мне просто любопытно, когда в коде потребуются случаи использования, когда кто -то потребуется более одного Tracesource.

Answer 1

Смотрите эти ответы на другие вопросы для хорошей отправной точки на использовании Tracesources:

Не удается понять .NET 2010 Трассирование и app.config

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

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

Одним из преимуществ наличия более одного трассура является то, что он увеличивает детализацию, при которой вы можете контролировать свою регистрацию. Например, если вы используете другой Tracesource в каждом классе, вы можете управлять журналом до уровня класса. Вы можете включить один (или несколько) конкретных классов и отключить все остальные.

Это общий шаблон для пользователей NLOG и Log4net. Типичная инициализация классов с использованием этих платформ для ведения журнала будет выглядеть примерно так:

public class A
{
  //NLog example
  private static Logger logger = LogManager.GetCurrentClassLogger();

  public F()
  {
    logger.Info("Inside F");
  }
}

В этом примере регистратор для класса A назван как полностью квалифицированное имя класса (NLOG выполняет тяжелую работу в GetCurrentClassLogger ()).

Чтобы сделать что -то подобное с Tracesource, вы бы сделали что -то вроде этого:

public class A
{
  private static TraceSource ts = new TraceSource(System.Reflection.GetCurrentMethod().DeclaringType.ToString();

  public F()
  {
    ts.Information("Inside F");
  }
}

Если вы делали это в каждом классе, вы можете легко контролировать, как вы ведете себя по классу.

Я не так уверен, что этот шаблон такой же распространен с Tracesource, как и с log4net и nlog. Я думаю, что вы могли бы чаще видеть, как пользователи Tracesource получают свои трассы по функциональной области.

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

public class FileReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from FileReader.F");
  }
}

public class NetworkReader
{
  private static TraceSource ts = new TraceSource("Read");

  public F()
  {
    ts.Information("Hello from NetworkReader.F");
  }
}

И так далее.

Теперь вы можете включить регистрацию для «чтения» и выключить для всех других функциональных областей (или включить регистрацию словесных заводов для «чтения» и менее многословного регистрации для всех остальных).

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

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

Поскольку вы смотрите на Tracesources, я бы посоветовал вам посмотреть этот проект в Codeplex:

http://ukadcdiagnostics.codeplex.com/

Это хороший проект (основанный на Tracesource), который позволяет форматировать выход для ведения журнала аналогично тому, что вы можете сделать с Log4net и NLOG.

Я также посоветовал вам взглянуть на эту журнальную обертку, построенную вокруг Tracesource из Castle.

https://github.com/castleproject/castle.core/blob/master/src/castle.core/core/logging/tracelogger.cs

Интересная вещь, которую они сделали, - это обеспечить иерархию именам Tracesource. Я реализовал что -то подобное в прошлом. Это работает довольно хорошо.

Мой ответ в этом вопросе дает представление о том, как может быть полезной иерархией трасесурсе:

Какой лучший подход к регистрации?

Удачи!