Когда мне нужно более одного TraceSource в коде? - PullRequest
Новая
       31

Когда мне нужно более одного TraceSource в коде?

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

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

1 Ответ

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

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

не может понять трассировку .net 2010 и app.config

Как использовать TraceSource для классов

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

Одним из преимуществ наличия более одного 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 получают свои TraceSources по функциональным областям.

Таким образом, вы можете разделить свое приложение на функции «Чтение», «Обработка» и «Запись» (или все, что имеет для вас смысл). В этом случае вы можете получить соответствующий 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. Таким образом, в ваших выходных данных будет легче разобраться в вашей регистрации, потому что вы, если вы решите это сделать, сравнительно легко найдут все сообщения регистрации, сгенерированные из определенной функциональной области (или определенного TraceSource).

Если у вас есть хорошее соглашение об именовании пространства имен, вы можете даже рассмотреть возможность получения 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. Я реализовал нечто подобное в прошлом. Это работает очень хорошо.

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

Какой лучший подход к ведению журнала?

Удачи!

...