2011-02-13 11 views
9

Ok, więc patrzę na NLog. Na podstawie użycia moja aplikacja byłaby powiązana z ramą logowania. Jak mam to przezwyciężyć?Moja struktura logowania jest na zawsze związana z moją aplikacją!

Ponadto, w przypadku korzystania z NLog, muszę napisać za dużo monkey-code dla każdej klasy, w której używam tego szkieletu. Czy dobrą praktyką jest tworzenie jednej klasy statycznej i uzyskiwanie do niej dostępu z dowolnego miejsca w mojej aplikacji?

przykład:

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

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

Odpowiedz

7
  1. Tworzenie własnego interfejsu rejestrowania:

    public interface IMyOwnLogger { 
        void Log(string message); 
    } 
    
  2. Tworzenie realizacja:

    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 do NLogLogger w swojej Pojemnik IOC.

  4. W razie potrzeby wstrzyknąć (lub użyć IOC.Get<IMyOwnLogger>()).

EDIT:

IDSA komentarz o utracie wzywającą klasę. Pamiętaj, że zawsze możesz użyć śledzenia stosu:

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

i wyciągnij klasę wywołania z tego miejsca.

EDIT:

ten sposób GetCurrentClassLogger w nlog wygląda, więc korzystanie StackTrace w naszej klasie nie stwarza dodatkowe obciążenie:

[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

Zgubiłeś interfejs w deklaracji klasy. Również lepiej "MyOwnLogger" zaakceptował instancję 'logger' jako parametr konstruktora - tak działa DI. – zerkms

+0

Nie ma znaczenia, że ​​LogManager.GetCurrentClassLogger ma sens: zostanie utworzony dla MyOwnLogger, ale nie dla prawdziwego miejsca, w którym rejestracja została nazwana – SiberianGuy

+0

@zerkms: Thanks. Dodałem interfejs. Klasa 'NLogLogger' jest implementacją IMyOwnLogger za pomocą NLog, więc nie musi rejestrować się w konstruktorze. – LukLed

2

Osobiście uniknąć związania wszelkie ramy do rejestrowania mój kod przy użyciu TraceSource do instrument mojego kodu. Następnie używam struktury rejestrowania (zazwyczaj biblioteki aplikacji Enterprise Logging Block), aby "nasłuchiwać" w celu śledzenia wyników w czasie wykonywania i robić to, co jest konieczne z tymi informacjami. (np. zapisywanie w bazie danych, wysyłanie wiadomości e-mail itp.)

+0

jaka jest wydajność tego? –

+0

Każdy rodzaj rejestrowania może mieć wpływ na wydajność w odpowiednich warunkach (obciążenie systemu itp.). Jeśli twoje pytanie ma na celu porównywanie wydajności Logging Framework z używaniem TraceSource i Trace Listeners, powiedziałbym, że można bezpiecznie założyć, że różnice w wydajności pomiędzy nimi są znikome. –

+0

Chciałbym również zwrócić uwagę, że instrumenty Microsoft własne biblioteki klas za pomocą Tracing. Doskonałym tego przykładem jest WCF (Windows Communication Foundation). Możesz przeczytać więcej na ten temat [tutaj] (http://msdn.microsoft.com/en-us/library/ms733025.aspx) –

Powiązane problemy