2011-02-13 4 views
9

Ok, quindi sto guardando NLog. In base all'utilizzo, la mia applicazione sarebbe legata al framework di registrazione. Come posso superare questo?Il mio framework di registrazione è legato alla mia applicazione per sempre!

Inoltre, quando si utilizza NLog, devo scrivere troppo monkey-code per ogni classe su cui sto utilizzando questo framework. È una buona pratica creare una classe statica e accedervi da qualsiasi punto della mia applicazione?

esempio:

//the monkey code 
private static Logger logger = LogManager.GetCurrentClassLogger(); 

//the coupling. 
logger.Log(/*...*/); 

risposta

7
  1. Creare la tua interfaccia di registrazione:

    public interface IMyOwnLogger { 
        void Log(string message); 
    } 
    
  2. Crea applicazione:

    public class NLogLogger : IMyOwnLogger { 
        void Log(string message) { 
         StackFrame frame = new StackFrame(1, false); 
         Logger logger = LogManager.GetLogger(frame.GetMethod().DeclaringType.FullName); 
         logger.Log(/*...*/); 
        } 
    } 
    
  3. Bind IMyOwnLogger al NLogLogger nella vostra Contenitore IOC.

  4. Iniettare dove necessario (oppure utilizzare IOC.Get<IMyOwnLogger>()).

EDIT:

IDSA ha lasciato un commento di perdere classe chiamando. Ricorda che puoi sempre utilizzare la traccia dello stack:

var method = (new StackTrace()).GetFrame(1).GetMethod() 

ed estrarre la classe chiamata da lì.

EDIT:

Questo è il modo in GetCurrentClassLogger NLog assomiglia, in modo da utilizzare StackTrace nella nostra classe non crea un ulteriore sovraccarico:

[MethodImpl(MethodImplOptions.NoInlining)] 
public static Logger GetCurrentClassLogger() 
{ 
    #if SILVERLIGHT 
    StackFrame frame = new StackTrace().GetFrame(1); 
    #else 
    StackFrame frame = new StackFrame(1, false); 
    #endif 

    return globalFactory.GetLogger(frame.GetMethod().DeclaringType.FullName); 
} 
+1

Hai perso l'interfaccia nella dichiarazione della classe. Inoltre sarebbe meglio che 'MyOwnLogger' accettasse l'istanza' logger' come parametro costruttore - cioè come funziona DI. – zerkms

+0

Non mi importa LogManager.GetCurrentClassLogger ha senso qui: verrà creato per MyOwnLogger ma non per il posto reale in cui è stato chiamato il logging – SiberianGuy

+0

@zerkms: Grazie. Ho aggiunto l'interfaccia. La classe 'NLogLogger' è l'implementazione di IMyOwnLogger che utilizza NLog, quindi non deve prendere il logger nel costruttore. – LukLed

2

Personalmente, ho evitare di bloccare qualsiasi quadro di registrazione per il mio codice utilizzando TraceSource a instrument il mio codice. Quindi utilizzo un framework di registrazione (tipicamente Logging Application Block di Enterprise Library) per "ascoltare" per tracciare l'output in fase di esecuzione e fare tutto ciò che è necessario con tali informazioni. (scrivere in un database, inviare e-mail, ecc.)

+0

qual è la prestazione di questo come? –

+0

Qualsiasi tipo di registrazione può avere impatti sulle prestazioni nelle giuste condizioni (carico del sistema, ecc.). Se la tua domanda è mirata a confrontare le prestazioni di un framework di registrazione e utilizzare TraceSource e gli ascoltatori di traccia, direi che è sicuro che le differenze di prestazioni tra i due siano trascurabili. –

+0

Vorrei anche sottolineare che Microsoft strumenta le proprie librerie di classi usando Tracing. Un primo esempio di ciò è WCF (Windows Communication Foundation). Puoi leggere di più a riguardo [qui] (http://msdn.microsoft.com/en-us/library/ms733025.aspx) –