11

私は .NET プロジェクトにログインするためにTraceSourceクラスを使用しています。

ただし、メソッドのidパラメーターの意図が何であるかは、私には明確ではありませんでした。TraceEvent現在、私は常に0に設定しています。

しかし、それの予想される、または典型的な有用な使用法は何ですか?

いくつかの可能性を考えることができます：

  • これはイベント発生の ID です (つまり、同じコード行が実行ごとに異なる ID を生成します)。
  • これはメソッド呼び出しの ID です (つまり、ID からコード行を推測できます)。
  • これは、類似したイベントのファミリーの ID です (たとえば、データベースが存在しないことを示すすべてのエラー メッセージは同じ ID を共有します)。
  • TraceEventType.(Start|Stop|Suspend|Resume|Transfer)これは、列挙値と組み合わせた、論理演算に関連する一連のイベントの IDです。
4

2 に答える 2

7

私は同じ質問を自問しましたが、マイクロソフトのドキュメントでこれを明確にするものは何も見つかりませんでした. 私がなんとか見つけたのは、Microsoft MVP の Richard Grimes が書いた記事です 。 彼はすべての例で id 引数に 0 を使用しています。

MSDN の記事では、追加情報を提供せずにランダムに使用されているのを見てきました。同じコード規則を維持している限り、ログを読むときに最も役立つ方法で使用できると思います。id 引数も受け入れるSourceFilter.ShouldTraceメソッドを使用する場合は、後でトレース フィルタリングで役立つことがわかります。

エラーがある場合はエラーの種類を説明するために使用し、それ以外の場合は 0 を使用します。

于 2013-08-13T13:55:48.473 に答える
4

私がドキュメンテーションで見た限りでは、それは特に 1 つの目的のために意図されたものではありません。イベントをトレースするための独自のロジックに結び付けることができると思います。ShouldTrace()メソッド onはSourceFilter一致するidパラメーターを受け取るため、それを使用して、どのイベントまたはイベントの種類がどこに行くかを判断することもできます。

個人的には、TraceSourceイベントの種類やカテゴリを追跡するために使用しています (最近発見したばかりなので、確かにそれほど多くはありません)。あるアプリケーションでは、別のロギング メソッドで使用していたイベント タイプの列挙型が既にあり、値は Debug、Info、Warn、Error、Fatal でした。そのため、それを にキャストしintて として使用しましたid。これは、後でフィルタリングするのに役立ちました。トレースを整理するために、関心のあるレベルより下のものを除外できます。

もう 1 つの可能性は、アプリケーションのさまざまな部分に関連するさまざまな値を使用できることです。つまり、データ アクセス = 1、ユーザー アカウント = 2、製品ロジック = 3、通知 = 4、UI = 5 などです。ここでも、これを使用できます。トレースをフィルタリングして、見ているもののタイプのみに絞り込みます。

または、(提案したように) 異なるid値を使用して異なるイベント タイプを意味することもできます。そのため、エラー コードのように使用して、(たとえば) id26 を見たときはいつでも、データベース接続ができなかったことがわかります。確立された、または何でも。

id次の条件を満たしている限り、パラメーターを何に使用するかは特に問題ではありません。

  • プログラムのビルドとデバッグに役立ちます
  • コードを読んでいるプログラマーにとって明確で理解しやすい
  • プログラム全体で一貫して使用されます

1 つの可能性は、イベントids を管理し、何らかの入力に基づいて値を提供する集中クラスを作成して、アプリケーション全体idが同じものを同じものに使用するようにすることです。

于 2013-08-13T14:08:49.733 に答える