Mejores prácticas de encapsuladores de registradores

Quiero usar un nlogger en mi aplicación, tal vez en el futuro necesite cambiar el sistema de registro. Entonces quiero usar una fachada de registro.

¿Conoce alguna recomendación de ejemplos existentes sobre cómo escribir esos? O simplemente dame un enlace a algunas de las mejores prácticas en esta área.

Solía ​​usar fachadas de registro como Common.Logging (incluso para ocultar mi propia biblioteca CuttingEdge.Logging ), pero hoy en día uso el patrón de Inyección de dependencia y esto me permite ocultar los registradores detrás de mi propia (simple) abstracción que se adhiere tanto a Dependency Principio de inversión y el principio de segregación de interfaces(ISP) porque tiene un miembro y porque mi aplicación define la interfaz; no una biblioteca externa. Minimizando el conocimiento que tienen las partes centrales de su aplicación sobre la existencia de bibliotecas externas, mejor; incluso si no tiene la intención de reemplazar su biblioteca de registro. La fuerte dependencia de la biblioteca externa hace que sea más difícil probar su código y complica su aplicación con una API que nunca fue diseñada específicamente para su aplicación.

Así es como suele verse la abstracción en mis aplicaciones:

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;
    }
}

Opcionalmente, esta abstracción se puede ampliar con algunos métodos de extensión simples (permitiendo que la interfaz se mantenga estrecha y siga adhiriéndose al ISP). Esto hace que el código para los consumidores de esta interfaz sea mucho más simple:

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.
}

Dado que la interfaz contiene solo un método, puede crear fácilmente una ILoggerimplementación que sustituye al log4net , a Serilog , Microsoft.Extensions.Logging , Nlog o cualquier otra biblioteca de registro y configurar el contenedor de DI para inyectarlo en las clases que tienen una ILoggeren su constructor.

Tenga en cuenta que tener métodos de extensión estáticos en la parte superior de una interfaz con un solo método es bastante diferente de tener una interfaz con muchos miembros. Los métodos de extensión son solo métodos auxiliares que crean un LogEntrymensaje y lo pasan a través del único método en la ILoggerinterfaz. Los métodos de extensión pasan a formar parte del código del consumidor; no forma parte de la abstracción. Esto no solo permite que los métodos de extensión evolucionen sin la necesidad de cambiar la abstracción, los métodos de extensión y laLogEntryconstructor siempre se ejecutan cuando se usa la abstracción del registrador, incluso cuando ese registrador es anulado / simulado. Esto brinda más certeza sobre la exactitud de las llamadas al registrador cuando se ejecuta en un conjunto de pruebas. La interfaz de un miembro también facilita las pruebas; Tener una abstracción con muchos miembros dificulta la creación de implementaciones (como simulacros, adaptadores y decoradores).

Cuando hace esto, casi nunca hay necesidad de alguna abstracción estática que las fachadas de registro (o cualquier otra biblioteca) puedan ofrecer.

Usé el pequeño contenedor de interfaz + adaptador de https://github.com/uhaciogullari/NLog.Interface que también está disponible a través de NuGet :

PM> Install-Package NLog.Interface 

A partir de ahora, la mejor opción es utilizar el paquete Microsoft.Extensions.Logging ( como señaló Julian ). La mayoría de los marcos de registro se pueden usar con esto.

Definir su propia interfaz, como se explica en la respuesta de Steven, está bien para casos simples, pero pasa por alto algunas cosas que considero importantes:

• Objetos de registro y desestructuración estructurados (la notación @ en Serilog y NLog)
• Construcción / formateo de cadenas retrasado: dado que toma una cadena, tiene que evaluar / formatear todo cuando se llama, incluso si al final el evento no se registrará porque está por debajo del umbral (costo de rendimiento, ver punto anterior)
• Comprobaciones condicionales como las IsEnabled(LogLevel)que desee, una vez más por motivos de rendimiento

Probablemente puedas implementar todo esto en tu propia abstracción, pero en ese momento estarás reinventando la rueda.

Generalmente prefiero crear una interfaz como

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

y en el tiempo de ejecución inyecto una clase concreta que se implementa desde esta interfaz.

Una gran solución a este problema ha surgido en forma del proyecto LibLog .

LibLog es una abstracción de registro con soporte incorporado para los principales registradores, incluidos Serilog, NLog, Log4net y Enterprise logger. Se instala a través del administrador de paquetes NuGet en una biblioteca de destino como un archivo de origen (.cs) en lugar de una referencia .dll. Ese enfoque permite que se incluya la abstracción del registro sin obligar a la biblioteca a asumir una dependencia externa. También permite al autor de una biblioteca incluir el registro sin forzar a la aplicación consumidora a proporcionar explícitamente un registrador a la biblioteca. LibLog usa la reflexión para averiguar qué registrador de concreto está en uso y conectarse a él sin ningún código de cableado explícito en los proyectos de la biblioteca.

Por lo tanto, LibLog es una gran solución para iniciar sesión en proyectos de biblioteca. ¡Simplemente haga referencia y configure un registrador de concreto (Serilog para ganar) en su aplicación o servicio principal y agregue LibLog a sus bibliotecas!

En lugar de escribir su propia fachada, puede utilizar Castle Logging Services o Simple Logging Façade .

Ambos incluyen adaptadores para NLog y Log4net.

Desde 2015, también puede usar .NET Core Logging si está creando aplicaciones .NET core.

El paquete para que NLog se conecte es:

• NLog.Web.AspNetCore para usuarios de ASP.NET Core
• NLog.Extensions.Logging para usuarios de .NET Core, por ejemplo, proyectos de consola