Best practice per il wrapper del logger

Voglio usare un nlogger nella mia applicazione, forse in futuro dovrò cambiare il sistema di registrazione. Quindi voglio usare una facciata di registrazione.

Conosci qualche consiglio per esempi esistenti su come scrivere quelli? Oppure dammi un link ad alcune best practice in questo settore.

Prima usavo le facciate di logging come Common.Logging (anche per nascondere la mia libreria CuttingEdge.Logging ), ma oggigiorno utilizzo il pattern Dependency Injection e questo mi permette di nascondere i logger dietro la mia (semplice) astrazione che aderisce a entrambe le dipendenze Principio di inversione e principio di segregazione dell'interfaccia(ISP) perché ha un membro e perché l'interfaccia è definita dalla mia applicazione; non una libreria esterna. Riducendo al minimo la conoscenza che le parti principali della tua applicazione hanno sull'esistenza di librerie esterne, meglio è; anche se non hai intenzione di sostituire mai la tua libreria di log. La forte dipendenza dalla libreria esterna rende più difficile testare il codice e complica la tua applicazione con un'API che non è mai stata progettata specificamente per la tua applicazione.

Ecco come appare spesso l'astrazione nelle mie applicazioni:

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

Facoltativamente, questa astrazione può essere estesa con alcuni semplici metodi di estensione (consentendo all'interfaccia di rimanere stretta e continuare ad aderire all'ISP). Questo rende il codice per i consumatori di questa interfaccia molto più semplice:

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

Dal momento che l'interfaccia contiene un solo metodo, è possibile creare facilmente ILoggerun'implementazione che proxy per log4net , a Serilog , Microsoft.Extensions.Logging , NLog o qualsiasi altra libreria di registrazione e configurare il contenitore DI iniettare in classi che hanno una ILoggerloro costruttore.

Si noti che avere metodi di estensione statici su un'interfaccia con un singolo metodo è abbastanza diverso dall'avere un'interfaccia con molti membri. I metodi di estensione sono solo metodi di supporto che creano un LogEntrymessaggio e lo passano attraverso l'unico metodo ILoggersull'interfaccia. I metodi di estensione diventano parte del codice del consumatore; non fa parte dell'astrazione. Ciò non solo consente ai metodi di estensione di evolversi senza la necessità di modificare l'astrazione, i metodi di estensione e ilLogEntryvengono sempre eseguiti quando viene utilizzata l'astrazione del logger, anche quando quel logger viene stubbed / deriso. Ciò fornisce maggiore certezza sulla correttezza delle chiamate al logger durante l'esecuzione in una suite di test. L'interfaccia a un membro rende anche i test molto più semplici; Avere un'astrazione con molti membri rende difficile creare implementazioni (come mock, adattatori e decoratori).

Quando si esegue questa operazione, non c'è quasi mai bisogno di un'astrazione statica che le facciate di registrazione (o qualsiasi altra libreria) potrebbero offrire.

Ho usato il piccolo wrapper di interfaccia + adattatore da https://github.com/uhaciogullari/NLog.Interface che è anche disponibile tramite NuGet :

PM> Install-Package NLog.Interface 

A partire da ora, la soluzione migliore è utilizzare il pacchetto Microsoft.Extensions.Logging ( come sottolineato da Julian ). La maggior parte dei framework di registrazione può essere utilizzata con questo.

Definire la propria interfaccia, come spiegato nella risposta di Steven, va bene per casi semplici, ma manca di alcune cose che considero importanti:

• Oggetti di registrazione e destrutturazione strutturati (la notazione @ in Serilog e NLog)
• Costruzione / formattazione della stringa ritardata: poiché prende una stringa, deve valutare / formattare tutto quando viene chiamato, anche se alla fine l'evento non verrà registrato perché è al di sotto della soglia (costo della prestazione, vedi punto precedente)
• Controlli condizionali come quello IsEnabled(LogLevel)che potresti desiderare, ancora una volta per motivi di prestazioni

Probabilmente puoi implementare tutto questo nella tua astrazione, ma a quel punto reinventerai la ruota.

In genere preferisco creare un'interfaccia come

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

e nel runtime inserisco una classe concreta che viene implementata da questa interfaccia.

Un'ottima soluzione a questo problema è emersa nella forma del progetto LibLog .

LibLog è un'astrazione di registrazione con supporto integrato per i principali logger tra cui Serilog, NLog, Log4net e Enterprise logger. Viene installato tramite il gestore dei pacchetti NuGet in una libreria di destinazione come file di origine (.cs) anziché come riferimento .dll. Questo approccio consente di includere l'astrazione della registrazione senza costringere la libreria ad assumere una dipendenza esterna. Consente inoltre all'autore di una libreria di includere la registrazione senza costringere l'applicazione in uso a fornire esplicitamente un logger alla libreria. LibLog utilizza la riflessione per capire quale logger concreto è in uso e collegarsi ad esso senza alcun codice di cablaggio esplicito nei progetti di libreria.

Quindi, LibLog è un'ottima soluzione per la registrazione all'interno di progetti di libreria. Basta fare riferimento e configurare un logger concreto (Serilog for the win) nella tua applicazione o servizio principale e aggiungi LibLog alle tue librerie!

Invece di scrivere la tua facciata, puoi utilizzare i servizi di registrazione del castello o la facciata di registrazione semplice .

Entrambi includono adattatori per NLog e Log4net.

Dal 2015 è possibile utilizzare anche .NET Core Logging se stai realizzando applicazioni .NET core.

Il pacchetto a cui NLog deve agganciarsi è:

• NLog.Web.AspNetCore per utenti ASP.NET Core
• NLog.Extensions.Logging per utenti .NET Core, ad esempio progetti di console