Что я должен идентифицировать с аргументом id в методе TraceSource.TraceEvent?

Я использую класс TraceSource для ведения журнала в моей .NET. проекты.

Однако мне никогда не было ясно, каково назначение параметра id в TraceEvent метод. В настоящее время я всегда устанавливаю его на 0.

Но каково его ожидаемое или типичное полезное использование?

Я могу придумать несколько возможностей:

  • Это идентификатор возникновения события (т. е. одна и та же строка кода создает разные идентификаторы при каждом выполнении);
  • Это идентификатор для вызова метода (т. е. вы можете вывести строку кода из идентификатора);
  • Это идентификатор для семейства подобных событий (например, все сообщения об ошибках, говорящие об отсутствии базы данных, имеют один и тот же идентификатор);
  • Это идентификатор набора событий, связанных с логической операцией, в сочетании с TraceEventType.(Start|Stop|Suspend|Resume|Transfer) значения перечисления;

.net c# system.diagnostics
person Jean Hominal    schedule 11.07.2013    source источник

Ответы (2)


arrow_upward
7
arrow_downward

Я задавал себе тот же вопрос и не нашел ничего, чтобы прояснить это в документации Microsoft. Что мне удалось найти, так это статью, написанную Microsoft MVP Ричардом Граймсом: "Параметр id равен что бы вы ни выбрали, нет принуждения, чтобы конкретный идентификатор был связан с сообщением определенного формата». Он использует 0 для аргумента идентификатора во всех примерах.

В статьях MSDN я видел, что он используется случайным образом, не предоставляя никакой дополнительной информации. Я считаю, что вы можете использовать любой способ, который лучше всего помогает вам при чтении журналов, если вы придерживаетесь того же соглашения о коде. Это может оказаться полезным впоследствии при фильтрации трассировки, если вы хотите использовать SourceFilter.ShouldTrace, который также принимает аргумент идентификатора.

Я использую его для описания типа ошибки, если у меня есть ошибка, или использую 0 для чего-либо еще.

person Catalin    schedule 13.08.2013
comment
Я полагаю (без доказательств), когда вы сначала TraceEvent() с идентификатором и сразу после TraceData() с тем же идентификатором, слушатели могут связать данные с событием?! Пример: сначала вы TraceEvent() создаете исключение, а сразу после него TraceData() трассируете стек. - person WiSeeker; 01.12.2016

arrow_upward
4
arrow_downward

Насколько я видел в документации, он не предназначен специально для одной цели. Я думаю, вы можете использовать свою собственную логику для отслеживания событий. Метод ShouldTrace() для SourceFilter принимает соответствующий параметр id, поэтому его также можно использовать для определения того, какие события или типы событий куда направляются.

Лично я, когда использую TraceSource (которого, по общему признанию, немного, поскольку открыл его совсем недавно), я использую его для отслеживания типов или категорий событий. В одном приложении у меня уже было перечисление для типов событий, которые я использовал с другим методом ведения журнала, со значениями Debug, Info, Warn, Error, Fatal, поэтому я привел его к int и использовал как id, что позже помогло с фильтрацией. поэтому я мог отфильтровать все, что ниже интересующего меня уровня, чтобы не загромождать трассировку.

Другая возможность заключается в том, что вы можете использовать разные значения для разных частей приложения, поэтому доступ к данным = 1, учетные записи пользователей = 2, логика продукта = 3, уведомления = 4, пользовательский интерфейс = 5 и т. д. Опять же, вы можете использовать это чтобы отфильтровать трассировку только по типу того, на что вы смотрите.

В качестве альтернативы вы можете (как вы предложили) использовать разные значения id для обозначения разных типов событий, чтобы вы могли использовать их как коды ошибок, чтобы (например) каждый раз, когда вы видели id из 26, вы знали, что соединение с базой данных может не быть установленным или что-то в этом роде.

Не имеет особого значения, для чего вы используете параметр id, если:

  • Это пригодится вам при сборке и отладке программы
  • Ясно и понятно программистам, читающим ваш код
  • Он используется последовательно на протяжении всей программы.

Одна из возможностей состоит в том, что у вас может быть централизованный класс, который управляет событием ids и предоставляет значения на основе какого-либо ввода, чтобы убедиться, что все приложение использует одно и то же id для одной и той же вещи.

person anaximander    schedule 13.08.2013