1

明確にするために、「アスペクト」の意味は、アプリケーションの機能の水平要素であり、アスペクト指向プログラミングのようにすべてのメソッド呼び出しをインターセプトするわけではありません。

.NET Trace インフラストラクチャ、特にTraceSourceオブジェクトの美しさを発見しました。この初心者のように、メソッドの開始と終了、エラーなどをトレースするために、各クラスに独自の TraceSource を与えました。

しかし、今はTraceSource側面ごとに 1 つの方が良いと思います。たとえば、駐車場内の車両移動の記録をインポートして、駐車料金を計算し、請求システム (WHMCS) にメッセージを投稿するアプリがあります。

TraceSource次のように、一連の静的プロパティを持つクラスが必要だと考えています。

public static class Traces
{
    static Traces()
    {
        VehicleMovements = new TraceSource("VehicleMovements", SourceLevels.All);
        Pricing = new TraceSource("Pricing", SourceLevels.All);
        Calculation = new TraceSource("Calculation", SourceLevels.All);
        Billing = new TraceSource("Billing", SourceLevels.All);
    }
    public static TraceSource VehicleMovements { get; set; }
    public static TraceSource Pricing { get; set; }
    public static TraceSource Calculation { get; set; }
    public static TraceSource Billing  { get; set; }
}

このようにして、たとえば、Traces.Pricing.VehicleMovements ("Terminal Id not configured");そのシナリオを見つけた任意のクラスで、より適切にグループ化され、よりまとまりのあるログまたはその他の出力を得ることができます。

これは良い考えですか？おまけとして、トレース戦略とパターンに関するリソースへのいくつかのポインターは素晴らしいでしょう、ありがとう.

4

2 に答える 2

1

申し訳ありませんが、これはプログラマー SE のような回答になります。あなたが示す特定のコードは、クラスベースのトレースではなく、テーマベースのトレースの良い例です。それが良いか悪いかは、生成しようとしているストーリーの種類と、そのストーリーが問題を理解してバグを見つけるために必要な情報を提供しているかどうかによって異なります。

私は痕跡の「強迫観念」を得て、著者が著名な開発者の束にインタビューし、どのようにデバッグするかを尋ねた本を読んだ後、すべてを追跡し始めました.ポイント。ですから、この慣行を形式化する方法があるかもしれません/あるべきですよね?

そこで、System.Diagnostics を使い始めました。主な利点は、いつでも利用できることです。これは欠陥のある API であり、nLogger と log4net はより洗練された API です。しかし、System.Diagnostics は拡張可能であり、多くの欠陥が修正されています。私は常に、Essential.Diagnostics および Ukadc ライブラリを System.Diagnostics およびいくつかの独自のカスタム リスナーと共に使用しています。

アスペクト指向トレース これは、各メソッド呼び出しの直前と直後にトレース ステートメントを追加することを意味します。これは非常におしゃべりで、エラーの時点で、スタック トレースとほとんど同じ情報を提供します。ほとんどのパフォーマンス トレースでは、この方法を使用して、呼び出された回数が多すぎるメソッドや、1 回の呼び出しまたは全体で時間がかかりすぎているメソッドを特定します。

クラスベースのトレース トレースは非常に速くおしゃべりになります。Microsoft では、トレースのページを「Spew」と呼んでいます。トレースされた内容について特に考えなければ、吐き出すだけで有益な情報になる可能性があります。これが、クラスごとに 1 つの TraceSource を使用する動機であり、関心のある 1 つまたは 2 つのクラスに対してのみトレースを有効にすることができます。

テーマ ベースのトレース クラスごとに TraceSource を使用しようとしましたが、私のアプリ (データベース中心の Web アプリ) にはテーマ ベースのトレースが本当に必要であることがわかりました。したがって、「perf」、「http」、「data」、「sql」、および「app」のトレース ソースがあります。Perf は実行時間に関連するもので、http は要求と応答に関する情報です。data は取得したデータを画面にダンプします。私のワークフローでは、特定の問題がない限り、テーマ ベースのトレースはほぼ常にオンにしており、クラス ベースのトレースは通常オフにしています。

本番/テスト チーム トレース トレースおよびエラー ログと多くの重複があります。トレースはストーリーを伝え、エラー ログは何が問題だったかを示します。トレースの収集にはコストがかかる場合がありますが、エラーが発生した時点までのトレースがあれば、役立つ場合があります。現時点では、本番環境ではトレースをメモリに書き込み、そのトレースを電子メールのエラー レポートに含めています。本番環境のトレースとエラーのログは、開発トレースよりも細かく調整する必要があります。これは、不適切なパフォーマンスや、重要でない問題をログに記録するために開発運用チームがエラー ログの重要なエラーを無視するなど、過度の噴出により劇的な結果が生じるためです。

これは、トレースの規範的なガイドラインを作成しようとしていたときに Trace について書いたブログ投稿ですhttp://suburbandestiny.com/Tech/?p=640 ため、API のような trace に対する一般的なアドバイス (この API は非常に強力です。必要に応じて使用できます! ) は、実際にはそれほど強力ではありません。

于 2013-06-13T11:29:24.937 に答える