Co powinienem zidentyfikować z argumentem id w metodzie TraceSource.TraceEvent?

Question

Używam klasy TraceSource do logowania do moich projektów .NET.

Punktem, który nigdy nie był dla mnie jasny, jest intencja parametru id w metodzie TraceEvent. Obecnie zawsze ustawiam go na 0.

Ale jakie jest oczekiwane lub typowe użyteczne użycie?

mogę myśleć kilka możliwości:

• Jest to identyfikator wystąpienia zdarzenia (czyli ten sam wiersz kodu wywołuje inny identyfikator każdego realizacji);
• Jest to identyfikator dla wywołania metody (tzn. Można wywnioskować wiersz kodu z identyfikatora);
• Jest to identyfikator dla rodziny podobnych zdarzeń (np. Wszystkie komunikaty o błędach, które mówią, że baza danych jest nieobecna mają ten sam identyfikator);
• Jest to identyfikator zestawu zdarzeń związanych z operacją logiczną w połączeniu z wartościami wyliczenia TraceEventType.(Start|Stop|Suspend|Resume|Transfer);

Answer 1

Zadałem sobie to samo pytanie i nie znalazłem niczego, co mogłoby to wyjaśnić w dokumentacji firmy Microsoft. Co udało mi się znaleźć to artykuł napisany przez Microsoft MVP, Richard Grimes: "The id parameter is whatever you choose it to be, there is no compulsion that a particular ID is associated with a particular format message." Używa 0, dla argumentu id, we wszystkich przykładach.

W artykułach MSDN widziałem, że był używany losowo, nie dostarczając żadnych dodatkowych informacji. Uważam, że można używać w jakikolwiek sposób, który pomaga najlepiej podczas czytania dzienników, o ile zachowuje się tę samą konwencję kodu. Może okazać się użyteczne później w filtrowaniu śledzenia, jeśli chcesz użyć metody SourceFilter.ShouldTrace, która akceptuje również argument id.

Używam go, aby opisać typ błędu, jeśli mam błąd, lub użyć 0 dla czegokolwiek innego.

Answer 2

O ile widziałem w dokumentacji, nie jest to specjalnie przeznaczone do jednego celu. Myślę, że jest tam, aby połączyć się z własną logiką w celu śledzenia wydarzeń. Metoda ShouldTrace() na SourceFilter przyjmuje pasujący parametr id, dzięki czemu można go również użyć do określenia, które zdarzenia lub typy zdarzeń mają miejsce.

Osobiście, gdy używam TraceSource (co wprawdzie nie jest zbyt wiele, odkąd odkryłem je dopiero niedawno) używam go do śledzenia typów zdarzeń lub kategorii. W jednej aplikacji miałem już wyliczenie dla typów zdarzeń, których używałem z inną metodą rejestrowania, z wartościami Debugowanie, Informacje, Ostrzeganie, Błąd, Śmierć, więc rzuciłem to na int i użyłem tego jako id, co pomogło później w filtrowaniu więc mogłem odfiltrować wszystko, co znajdowało się poniżej poziomu, który mnie interesował, aby usunąć ślady.

Inną możliwością jest użycie różnych wartości do powiązania z różnymi częściami aplikacji, więc dostęp do danych = 1, Konta użytkowników = 2, Logika produktu = 3, Powiadomienia = 4, UI = 5 itd. Znowu, ty może użyć tego do filtrowania śladu w dół tylko do typu rzeczy, na którą patrzysz.Alternatywnie, możesz (zgodnie z sugestią) użyć różnych wartości id do oznaczania różnych typów zdarzeń, aby można było używać ich jak kodów błędów, aby (na przykład) za każdym razem, gdy zobaczyłeś id z 26 nie można ustanowić połączenia z bazą danych lub cokolwiek innego.

Nie szczególnie ważne czego użyć parametru id na tak długo, jak:

• Jest przydatna w budowaniu i debugowania programu
• To jest jasne i zrozumiałe dla programistów czytania przez kod
• jest on stosowany konsekwentnie w całym programie

Jedną z możliwości jest to, że można mieć scentralizowany klasę, że człowiek starzeje się zdarzenie id s i podaje wartości oparte na pewnym rodzaju danych wejściowych, aby upewnić się, że cała aplikacja używa tego samego obiektu id.