ロガーラッパーのベストプラクティス

Question 1

アプリケーションでnloggerを使用したいのですが、将来的には、ログシステムを変更する必要があります。だから私はロギングファサードを使いたいです。

既存の例の推奨事項を、それらの記述方法を知っていますか？または、この分野のベストプラクティスへのリンクを教えてください。

Question 2

Common.Loggingなどのロギングファサードを使用していました（自分のCuttingEdge.Loggingライブラリを非表示にする場合でも）が、現在は依存関係注入パターンを使用しているため、両方の依存関係に準拠する独自の（単純な）抽象化の背後にロガーを非表示にできます逆転の原理とインターフェース分離の原理（ISP）メンバーが1つであり、インターフェースがアプリケーションによって定義されているため。外部ライブラリではありません。アプリケーションのコア部分が外部ライブラリの存在について持っている知識を最小限に抑えることは、より良いことです。ロギングライブラリを置き換える意図がない場合でも。外部ライブラリへの依存度が高いため、コードのテストが難しくなり、アプリケーション用に特別に設計されたことのないAPIでアプリケーションが複雑になります。

これは、私のアプリケーションで抽象化がよく見えるものです。

public interface ILogger
{
    void Log(LogEntry entry);
}

public enum LoggingEventType { Debug, Information, Warning, Error, Fatal };

// Immutable DTO that contains the log information.
public class LogEntry 
{
    public readonly LoggingEventType Severity;
    public readonly string Message;
    public readonly Exception Exception;

    public LogEntry(LoggingEventType severity, string message, Exception exception = null)
    {
        if (message == null) throw new ArgumentNullException("message");
        if (message == string.Empty) throw new ArgumentException("empty", "message");

        this.Severity = severity;
        this.Message = message;
        this.Exception = exception;
    }
}

必要に応じて、この抽象化をいくつかの単純な拡張メソッドで拡張できます（インターフェイスが狭いままで、ISPに準拠し続けることができます）。これにより、このインターフェースのコンシューマー向けのコードがはるかに単純になります。

public static class LoggerExtensions
{
    public static void Log(this ILogger logger, string message) {
        logger.Log(new LogEntry(LoggingEventType.Information, message));
    }

    public static void Log(this ILogger logger, Exception exception) {
        logger.Log(new LogEntry(LoggingEventType.Error, exception.Message, exception));
    }

    // More methods here.
}

インターフェイスには単一のメソッドしか含まれていないため、log4net、Serilog、Microsoft.Extensions.Logging、NLog、またはその他のログライブラリのプロキシとなるILogger実装を簡単に作成し、DIコンテナーを構成して、コンストラクタ。ILogger

単一のメソッドを持つインターフェースの上に静的な拡張メソッドを持つことは、多くのメンバーを持つインターフェースを持つこととはかなり異なることに注意してください。拡張メソッドは、LogEntryメッセージを作成し、それをILoggerインターフェース上の唯一のメソッドに渡すヘルパーメソッドにすぎません。拡張メソッドは、消費者のコードの一部になります。抽象化の一部ではありません。これにより、抽象化、拡張メソッド、およびLogEntryロガーがスタブ化またはモック化されている場合でも、ロガー抽象化が使用されると、コンストラクターは常に実行されます。これにより、テストスイートで実行した場合のロガーへの呼び出しの正確さがより確実になります。1メンバーのインターフェースにより、テストもはるかに簡単になります。多くのメンバーを持つ抽象化があると、実装（モック、アダプター、デコレーターなど）の作成が難しくなります。

これを行う場合、ロギングファサード（またはその他のライブラリ）が提供する静的な抽象化はほとんど必要ありません。

Question 3

私はhttps://github.com/uhaciogullari/NLog.Interfaceの小さなインターフェイスラッパー+アダプターを使用しました。

PM> Install-Package NLog.Interface

Question 4

現在、最善の策は、Microsoft.Extensions.Loggingパッケージを使用することです（Julianによって指摘されています）。ほとんどのロギングフレームワークはこれで使用できます。

Stevenの回答で説明されているように、独自のインターフェースを定義することは、単純なケースでは問題ありませんが、私が重要だと考えるいくつかのことを欠いています。

構造化されたロギングおよび構造化解除オブジェクト（SerilogおよびNLogの@表記）
遅延文字列の構築/フォーマット：文字列を取得するため、呼び出されたときにすべてを評価/フォーマットする必要があります。最終的にはしきい値を下回ったためにイベントがログに記録されません（パフォーマンスコスト、前のポイントを参照）。
IsEnabled(LogLevel)パフォーマンス上の理由から、希望する条件付きチェックをもう一度

おそらく、これらすべてを独自の抽象化で実装できますが、その時点で車輪を再発明することになります。

Question 5

一般的に私は次のようなインターフェースを作成することを好みます

public interface ILogger
{
 void LogInformation(string msg);
 void LogError(string error);
}

ランタイムでは、このインターフェイスから実装される具象クラスを注入します。

Question 6

この問題に対する優れた解決策は、LibLogプロジェクトの形で現れました。

LibLogは、Serilog、NLog、Log4net、Enterpriseロガーなどの主要なロガーを組み込みでサポートするロギング抽象化です。NuGetパッケージマネージャーを介して、.dll参照ではなくソース（.cs）ファイルとしてターゲットライブラリにインストールされます。このアプローチにより、ライブラリーに外部依存関係を強制することなく、ロギングの抽象化を組み込むことができます。また、ライブラリの作成者が、使用するアプリケーションにライブラリにロガーを明示的に提供させることなく、ロギングを含めることができます。LibLogはリフレクションを使用して、どの具体的なロガーが使用されているかを把握し、ライブラリプロジェクトの明示的な配線コードなしでそれに接続します。

したがって、LibLogは、ライブラリプロジェクト内のロギングに最適なソリューションです。メインのアプリケーションまたはサービスで具象ロガー（勝利のためのSerilog）を参照して構成し、LibLogをライブラリに追加するだけです！

Question 7

独自のファサードを作成する代わりに、Castle Logging ServicesまたはSimple LoggingFaçadeを使用できます。

どちらにもNLogとLog4netのアダプターが含まれています。

Question 8

2015年以降、.NETコアアプリケーションを構築する場合は、.NETコアロギングを使用することもできます。

NLogがフックするパッケージは次のとおりです。

ASP.NET CoreユーザーのNLog.Web.AspNetCore
.NET Coreユーザー向けのNLog.Extensions.Logging（例：コンソールプロジェクト）