Quale modello utilizzare per la registrazione? Iniezione delle dipendenze o localizzatore di servizi?

Question

Considerare questo scenario. Ho una logica di business che di tanto in tanto sarà necessario scrivere su un log.

interface ILogger 
{ 
    void Log(string stuff); 
} 

interface IDependency 
{ 
    string GetInfo(); 
} 

class MyBusinessObject 
{ 
    private IDependency _dependency; 

    public MyBusinessObject(IDependency dependency) 
    { 
     _dependency = dependency; 
    } 

    public string DoSomething(string input) 
    { 
     // Process input 
     var info = _dependency.GetInfo(); 
     var intermediateResult = PerformInterestingStuff(input, info); 

     if (intermediateResult== "SomethingWeNeedToLog") 
     { 
      // How do I get to the ILogger-interface? 
     } 

     var result = PerformSomethingElse(intermediateResult); 

     return result; 
    } 
} 

Come si ottiene l'interfaccia di ILogger? Vedo due possibilità principali;

1. Passarlo utilizzando Iniezione di dipendenza sul costruttore.
2. Scaricalo tramite un localizzatore di servizi singleton.

Quale metodo preferiresti e perché? O c'è un modello ancora migliore?

Aggiornamento: Nota che non è necessario registrare TUTTE le chiamate di metodo. Voglio solo registrare alcuni (rari) eventi che potrebbero verificarsi o meno nel mio metodo.

Answer 1

Io personalmente faccio una miscela di entrambi.

Qui sono le mie convenzioni:

• Da un contesto statico - Servizio Ubicazione
• da un contesto esempio - Dependency Injection

Sento che questo mi dà il giusto equilibrio di testabilità. Trovo un po 'più difficile configurare i test rispetto alle classi che usano Service Location che usare DI, quindi questo è il motivo per cui Service Location finisce per essere l'eccezione piuttosto che la regola. Sono coerente nel suo uso, però, quindi non è difficile ricordare quale tipo di test ho bisogno di scrivere.

Alcuni hanno sollevato la preoccupazione che DI tende a ingombrare i costruttori. Non credo che questo sia un problema, ma se ti senti in questo modo, ci sono un certo numero di alternative che usano DI, ma evitano i parametri del costruttore. Ecco un elenco dei metodi DI di Ninject: http://ninject.codeplex.com/wikipage?title=Injection%20Patterns

Troverete che la maggior parte dei contenitori di Inversion of Control ha le stesse caratteristiche di Ninject. Ho scelto di mostrare Ninject perché hanno i campioni più concisi.

Speriamo che questo sia utile.

Edit: Per essere chiari, io uso l'Unità e Common Service Locator. Ho un'istanza singleton del mio contenitore Unity per DI e la mia implementazione di IServiceLocator è semplicemente un wrapper attorno al container Unity di singleton. In questo modo non devo fare alcun tipo di mappatura due volte o qualcosa del genere.

Inoltre, non ritengo che AOP sia particolarmente utile oltre il tracciamento. Mi piace la registrazione manuale più semplicemente per la sua chiarezza. So che la maggior parte dei framework di registrazione AOP è in grado di entrambi, ma non ho bisogno del primo (pane e burro AOP) la maggior parte del tempo. Questa è solo una preferenza personale, ovviamente.

Answer 2

DI funzionerebbe bene qui. Un'altra cosa da guardare sarebbe AOP.

Answer 3

Non consiglierei nessuno di questi approcci. Meglio usare la programmazione orientata all'aspetto. La registrazione è il "mondo ciao" di AOP.

Answer 4

Preferirei Singleton Service.

L'iniezione di dipendenza ingombra il costruttore.

Se è possibile utilizzare AOP, questo sarebbe il migliore.

Answer 5

Abbiamo commutato tutti gli attributi di Logging/Tracciamento in PostSharp (AOP framework). Tutto ciò che devi fare per creare la registrazione per un metodo è aggiungere l'attributo ad esso.

Vantaggi:

• facile utilizzo di AOP
• Chiaro separazione degli interessi
• avviene al momento della compilazione ->impatto sulle prestazioni minimo

Controlla this.

Answer 6

È possibile derivare un altro tipo, ad es. LoggableBusinessObject che accetta un logger nel suo costruttore. Questo significa che si passa solo nel registratore per gli oggetti che lo utilizzeranno:

public class MyBusinessObject 
{ 
    private IDependency _dependency; 

    public MyBusinessObject(IDependency dependency) 
    { 
     _dependency = dependency; 
    } 

    public virtual string DoSomething(string input) 
    { 
     // Process input 
     var info = _dependency.GetInfo(); 
     var result = PerformInterestingStuff(input, info); 
     return result; 
    } 
} 

public class LoggableBusinessObject : MyBusinessObject 
{ 
    private ILogger _logger; 

    public LoggableBusinessObject(ILogger logger, IDependency dependency) 
     : base(dependency) 
    { 
     _logger = logger; 
    } 

    public override string DoSomething(string input) 
    { 
     string result = base.DoSomething(input); 
     if (result == "SomethingWeNeedToLog") 
     { 
      _logger.Log(result); 
     } 
    } 
} 

Answer 7

Il logger è chiaramente un servizio da cui dipende la logica aziendale e deve quindi essere considerato come una dipendenza nello stesso modo in cui si fa con IDependency. Inietti il ​​logger nel tuo costruttore.

Nota: anche se AOP è menzionato come il modo per iniettare la registrazione non sono d'accordo che sia la soluzione in questo caso. AOP funziona perfettamente per la traccia di esecuzione, ma non sarà mai una soluzione per la registrazione come parte della logica aziendale.

Answer 8

La mia piccola regola:

• Se è in una libreria di classi, utilizzare uno di iniezione del costruttore o l'iniezione di proprietà con un modello null-oggetto.

• Se si trova in un'applicazione principale, utilizzare il localizzatore di servizio (o singleton).

Trovo che questo si applica piuttosto bene quando si utilizza log4net. Non vuoi che le librerie di classi raggiungano cose che potrebbero non esserci, ma in un programma applicativo, sai che il logger sarà lì, e le librerie come log4net sono basate pesantemente sul modello di posizione del servizio.

Tendo a considerare la registrazione come qualcosa di sufficientemente statico da non richiedere effettivamente DI. È estremamente improbabile che io possa mai cambiare l'implementazione della registrazione in un'applicazione, soprattutto perché ogni framework di registrazione è incredibilmente flessibile e facile da estendere. È più importante nelle librerie di classi quando la tua biblioteca potrebbe aver bisogno di essere utilizzata da diverse applicazioni che già utilizzano diversi logger.

YMMV, ovviamente. DI è grande ma ciò non significa che tutto debba essere eliminato.

Answer 9

Forse questo sarà poco offtopic, ma perché abbiamo bisogno di iniettare logger a tutti, quando possiamo semplicemente digitare al beggining della classe:

Logger logger = LogManager.GetLogger("MyClassName"); 

Logger non cambia durante lo sviluppo e successivamente durante Manutenzione. I moderni logger sono altamente personalizzabili, quindi argomento

e se volessi sostituire il registratore di testi con il database?

mancato.

Non negare l'utilizzo della dipendenza, sono solo curioso della tua mente.