0

バージョニングに関して、セマンティック ログ アプリケーション ブロックのドキュメントでは次のことを推奨しています。

EventSource クラスを変更する必要がある場合は、新しいログ メッセージをサポートするメソッドの追加と、既存のメソッドのオーバーロードの追加 (新しいイベント ID を持つ) に変更を制限する必要があります。既存のメソッドの署名を削除または変更しないでください。

次の EventSource クラスがあるとします。

[EventSource(Name = "Instrumentation")]
public class InstrumentationEventSource : EventSource {
    private static readonly Lazy<InstrumentationEventSource> Singleton = new Lazy<InstrumentationEventSource>(() => new InstrumentationEventSource());

    public static InstrumentationEventSource Log { get { return Singleton.Value; } }

    private InstrumentationEventSource() {}

    [Event(eventId: 901)]
    public void EndPage(string url) {
        WriteEvent(901, url);
    }
}

そして、クエリ文字列のログ記録のサポートを追加したいと考えました。同じ ID を持つオーバーロードされたメソッドを追加できますか?

[Event(eventId: 901)]
public void EndPage(string url) {
    WriteEvent(901, url);
}

[Event(eventId: 901)]
public void EndPage(string url, string queryString) {
    WriteEvent(901, url, queryString);
}

アプリケーションやプロセス外のホスト ログ アプリケーションへの影響を最小限に抑えながら、将来の変更をサポートするにはどうすればよいですか?

モデルクラスに追加することで、署名をよりシンプルに保つことができますか?

public class LogData {
    public string url { get; set; }
    // public string queryString { get; set; }
}

と

[Event(eventId: 901)]
public void EndPage(LogData data) {
    WriteEvent(901, data);
    // Or does the params object[] args parameter not support classes?
    // WriteEvent(901, data.url);
    // And this would have to be changed anyway?
    // WriteEvent(901, data.url, data.queryString);
}

Event ID が全体のどこに当てはまるのか、クラスのメンテナンスでこれにどれだけのEventSource注意を払う必要があるのか​​、私にはよくわかりません。

4

1 に答える 1