9

Semantic Logging Application Block (SLAB) は私にとって非常に魅力的であり、私が作成している大規模な複合アプリケーションで使用したいと考えています。これを使用するには、'EventSource' から派生したクラスを作成し、単純な文字列ではなく、型指定されたイベントとしてログに記録するイベントごとに 1 つのメソッドをクラスに含めます。

私のようなアプリケーションには、そのようなイベントが何百もある可能性があります。「SomethingHappened」という 1 つのイベントだけを含む「EventSource」ベースのクラスを作成し、それを介してすべてをログに記録し、労力と正確さのスペクトルの極端な端に置き、実行する操作ごとに 1 つのイベントを作成することができます。

さまざまな機能領域に EventSource の派生物を用意するのは良い考えだと思います。アプリは、ビジネス ロジック自体をほとんど知りません。これはすべて MEF プラグイン モジュールによって提供されるため、ブートラップ、セキュリティ、構成変更などのイベント ソースを使用できます。プラグイン モジュールは、ログに記録するイベントのイベント ソースを定義できます。

これは良い戦略ですか、それとも多くのEventSource派生ロガーはアプリの望ましくない機能ですか?

4

4 に答える 4

0

イベントを 1 つの大きなファイルではなく、別の小さなプロバイダー (EventSource クラス) に論理的にグループ化します。

これには、特別な場合に関心のあるプロバイダーに対してのみイベントを有効にできるという利点があります。

于 2014-04-11T18:50:10.190 に答える
0

EventSource を、アプリケーションで実行できる可能性のあるすべてのログ イベントのリストと考えないでください。キーワードと詳細度/イベント レベルを使用してイベントをフィルタリングする方法があることに注意してください。さらに掘り下げて、OpCodes と Tasks を使用することもできます。SLAB のバージョン 1.1 は、ActivityID と RelatedActivityID をサポートしています。今週初めにリリースされたバージョン 2.0 ( https://slab.codeplex.com/wikipage?title=SLAB2.0ReleaseNotes&version=2 ) は、プロセスとスレッド ID をサポートするようになりました。

例を挙げると、非常に小さな EventSource 派生クラスがあり、StartLog、LogStatus、StopLogging、LogError、LogDebug、および CreateDump のメソッドがあり、最初の 3 つは同じイベント レベルを使用しますが、フォーマットと残りの違いによりイベント ID が異なります。 1つは異なるイベントレベルを使用するため、構成ファイルの設定で動的に有効にしない限り、ダンプをデバッグしたり作成したりしません。ポイントは、asp.net サイトだけでなく、クラス ライブラリやコンソール アプリからも同じメソッドを使用できることです。これはロギング イベントのみを定義することを忘れないでください。シンクがイベントをサブスクライブする必要があるため、より多くの可能性が得られます。デバッグ メッセージをファイルに送信し、エラー メッセージをデータベースや電子メールに送信することができます。可能性は無限大。

最後に一つだけ。テストを行ったときに自分自身を隅に追いやったと思ったのですが、複数のアセンブリが同じイベント メソッド (したがって、同じイベント ID、キーワード、イベント レベルなど) を使用していたため、同じファイルにログを記録していることがわかりました。ログ メッセージを書き込む必要があるかどうか (構成ファイルの設定から) および場所 (アセンブリ名に基づくログ ファイル) を決定するときに、フィルター プロセスで現在使用されている呼び出し元のアセンブリ名を渡すようにコードを変更しました。お役に立てれば！

于 2014-07-08T17:14:11.997 に答える