로거 래퍼 모범 사례

내 응용 프로그램에서 nlogger를 사용하고 싶습니다. 나중에 로깅 시스템을 변경해야 할 수도 있습니다. 그래서 저는 로깅 파사드를 사용하고 싶습니다.

기존 예제를 작성하는 방법에 대한 권장 사항을 알고 있습니까? 또는이 분야의 모범 사례에 대한 링크를 제공하십시오.

Common.Logging 과 같은 로깅 파사드를 사용 했지만 (저의 CuttingEdge.Logging 라이브러리 를 숨기는 경우에도 ) 요즘에는 Dependency Injection 패턴을 사용 하며이를 통해 두 종속성 을 모두 준수하는 내 자신의 (간단한) 추상화 뒤에 로거를 숨길 수 있습니다. 반전 원리 와 인터페이스 분리 원리(ISP) 멤버가 하나 있고 인터페이스가 내 애플리케이션에 의해 정의되기 때문입니다. 외부 라이브러리가 아닙니다. 애플리케이션의 핵심 부분이 외부 라이브러리의 존재에 대한 지식을 최소화하는 것이 좋습니다. 로깅 라이브러리를 교체 할 의도가없는 경우에도 마찬가지입니다. 외부 라이브러리에 대한 엄격한 종속성으로 인해 코드 테스트가 더 어려워지고 애플리케이션을 위해 특별히 설계되지 않은 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.
}

인터페이스는 단지 하나의 방법을 포함하기 때문에, 당신은 쉽게 만들 수 있습니다 ILogger구현하는 log4net에 프록시 , Serilog에 , Microsoft.Extensions.Logging , NLog 또는 다른 로깅 라이브러리를하고이 클래스에 주입하기 위해 DI 컨테이너를 구성 ILogger에서 자신의 건설자.

단일 메서드가있는 인터페이스 위에 정적 확장 메서드를 사용하는 것은 많은 멤버가있는 인터페이스를 사용하는 것과 상당히 다릅니다. 확장 메서드는 LogEntry메시지 를 만들고 ILogger인터페이스 의 유일한 메서드를 통해 전달 하는 도우미 메서드 일뿐 입니다. 확장 메서드는 소비자 코드의 일부가됩니다. 추상화의 일부가 아닙니다. 이것은 추상화, 확장 방법 및 확장 방법을 변경할 필요없이 확장 방법을 발전시킬 수있을뿐만 아니라LogEntry생성자는 로거 추상화가 사용될 때 항상 실행됩니다. 심지어 해당 로거가 스텁 / 모의 된 경우에도 마찬가지입니다. 이것은 테스트 스위트에서 실행될 때 로거에 대한 호출의 정확성에 대해 더 확실하게합니다. 1 인 인터페이스는 테스트를 훨씬 쉽게 만듭니다. 많은 구성원이있는 추상화를 사용하면 구현 (예 : 모의, 어댑터 및 데코레이터)을 만들기가 어렵습니다.

이렇게하면 로깅 파사드 (또는 다른 라이브러리)가 제공 할 수있는 정적 추상화가 거의 필요하지 않습니다.

나는에서 + 어댑터 래퍼 작은 인터페이스를 사용 https://github.com/uhaciogullari/NLog.Interface 또한 그 NuGet을 통해 가능합니다 :

PM> Install-Package NLog.Interface 

현재로서는 가장 좋은 방법은 Microsoft.Extensions.Logging 패키지 를 사용하는 것입니다 (Julian가 지적한대로 ). 대부분의 로깅 프레임 워크를 이것과 함께 사용할 수 있습니다.

Steven의 답변에 설명 된대로 고유 한 인터페이스를 정의하는 것은 간단한 경우에 적합하지만 중요하다고 생각하는 몇 가지 사항이 누락되었습니다.

• 구조화 된 로깅 및 구조 해제 객체 (Serilog 및 NLog의 @ 표기법)
• 지연된 문자열 구성 / 포맷 : 문자열을 가져 오므로 호출시 모든 것을 평가 / 포맷해야합니다. 결국 이벤트가 임계 값 (성능 비용, 이전 포인트 참조) 미만이기 때문에 기록되지 않더라도
• IsEnabled(LogLevel)다시 한 번 공연상의 이유로 원하는 조건부 검사

이 모든 것을 자신의 추상화로 구현할 수 있지만 그 시점에서 바퀴를 재발 명하게 될 것입니다.

일반적으로 나는 다음과 같은 인터페이스를 만드는 것을 선호합니다.

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

런타임에서이 인터페이스에서 구현 된 구체적인 클래스를 삽입합니다.

이 문제에 대한 훌륭한 해결책이 LibLog 프로젝트 의 형태로 나타났습니다 .

LibLog는 Serilog, NLog, Log4net 및 Enterprise 로거를 포함한 주요 로거에 대한 지원이 내장 된 로깅 추상화입니다. NuGet 패키지 관리자를 통해 대상 라이브러리에 .dll 참조 대신 소스 (.cs) 파일로 설치됩니다. 이러한 접근 방식을 사용하면 라이브러리가 외부 종속성을 가지지 않고도 로깅 추상화를 포함 할 수 있습니다. 또한 라이브러리 작성자는 사용하는 응용 프로그램이 라이브러리에 로거를 명시 적으로 제공하지 않고도 로깅을 포함 할 수 있습니다. LibLog는 리플렉션을 사용하여 사용중인 구체적인 로거를 파악하고 라이브러리 프로젝트에서 명시적인 배선 코드없이 연결합니다.

따라서 LibLog는 라이브러리 프로젝트 내에서 로깅을위한 훌륭한 솔루션입니다. 메인 애플리케이션 또는 서비스에서 구체적인 로거 (승리를위한 Serilog)를 참조하고 구성하고 라이브러리에 LibLog를 추가하십시오!

자신 만의 파사드를 작성하는 대신 Castle Logging Services 또는 Simple Logging Façade를 사용할 수 있습니다 .

둘 다 NLog 및 Log4net 용 어댑터를 포함합니다.

2015 년부터 .NET Core 애플리케이션을 빌드하는 경우 .NET Core 로깅을 사용할 수도 있습니다 .

NLog에 연결할 패키지는 다음과 같습니다.

• ASP.NET Core 사용자를위한 NLog.Web.AspNetCore
• .NET Core 사용자를위한 NLog.Extensions.Logging ( 예 : 콘솔 프로젝트)