Abhängigkeit zu einer bestimmten Logging-Bibliothek vermeiden

Hallo!
Ich habe da eine eher generelle Frage.
Konkret geht es um eine Logging-Komponente. Ich habe eine gemeinsam genutzte Bibliothek (*.Common.dll). Diese wird in ca. 20 Anwendungen verwendet. Nun wollte ich eine Logging-Funktionalität einbauen. Ich möchte NLog nutzen.
Nun würde ich aber gerne unabhängig von einem konkreten Anbieter bleiben.
Wie kann ich das erreichen?
Muss ich mir umständlich einen eigenen Wrapper schreiben oder gibt es da vielleicht schon was fertiges?
So ein Logger hat ja doch schon einiges an Funtionalität und das alles nochmal zu wrappen ist ganz schön aufwendig.
Wie macht ihr sowas? Seid ihr abhängig von einem Anbieter und nutzt dann immer in jedem Projekt eine referenz auf dessen .dll?

Wir hier in der Firma nutzen zum loggen die Microsoft Enterprise Library, die hat soweit eigentlich das was wir so brauchen...

Hallo Froggie,

die Frage ist, wie wahrscheinlich ist ein Wechsel von einem Anbieter zu einem anderen multipliziert mit dem Umstellungsaufwand, der dann anfällt, im Vergleich zu dem Aufwand, einen Wrapper zu schreiben, der dann so generell/abstrakt/flexibel ist, dass man ihn später auch tatsächlich auf die Bibliothek eines anderen Anbieters anpassen kann.

Meine Vermutung ist, dass es in der Praxis vorwiegend zwei Lösungen gibt. Entweder from scratch einen eigenen Logger schreiben (das ist viel Aufwand, aber man hat dann auch die volle Kontrolle) oder direkt eine bestimmte Fremdbibliothek verwenden (und sich damit in eine gewissen Abhängigkeit begeben).

herbivore

@Froggie:
Welche Funktionalität benötigen denn deine routinen, die dein Logger zur verfügung stellen muss?

Write und WriteLine für verschiedene objekte und das mit verschiedenen Detailgraden.
Das was Du benötigst, packst du in ein ILogger interface, und lässt dir immer den entsprechenden Logger injecten ( einer der grossen vorteile von IOC ).

    public interface ILogger
    {
        enLogLevel DisplayLevel { get; set; }
        void Close();
        void Write(enLogLevel logLevel, string lineToWrite, params object[] para);
        void WriteLine(enLogLevel logLevel, string lineToWrite, params object[] para);
    }

viel mehr brauchen deine Komponenten ja nich tzu wissen.
Nur an der Stelle wo du den konkreten Logger erstellst, muss Du alles hierzu wissen, und da muss ja nichts gewrappt werden.

Schau dir dazu evtl auch mal den CommonServiceLocator an, der kapselt ja auch "beliebige" IOC Container mit einem sehr einfachen interface.

Hi,

ich persönlich bin einer von der Sorte, der seine eigene Protokoll-Bibliothek implementiert, die dann überall gleich verwendet wird. Zusätzlich gibt es auch ein gemeinsames Auswertetool. Grundsätzlich gebe ich aber herbivore recht, die meistens habens entweder selber gemacht oder nutzen von vorne herein eine Fremdbibliothek.

Ein allgemeines Interface und IOC und solche Sachen finde ich persönlich schon fast etwas übertrieben fürs Logging. In meinen Augen sollte Protokollierung in den eigenen Programmen möglichst überall gleich sein, damit die Auswertung der Protokolle auch überall auf den gleichen Weg geschehen kann. Aber gut, hier denkt vermutlich jeder etwas anders.

Gruß
Roland

Hallo Blacal,

Ein allgemeines Interface und IOC und solche Sachen finde ich persönlich schon fast etwas übertrieben fürs Logging.

Vom Implementierungsaufwand her ist es ja nicht viel. Aber was gewinnt man dem Interface:*keine starrre Abhängigkeit zum Logger *es kann der Logger getauscht werden (könnte ja sein) *auch das Loggen ist testbar *...

Ich halte es so wei FZelle.

mfG Gü

Hallo zusammen,

was mir gerade noch einfällt: gerade im Zusammengang mit Logging darf man aspektorientierte Programmierung (AOP) nicht unerwähnt lassen. Da dann im Extremfall gar kein Logging Code im Quellcode nötig ist, kann man damit direkt Abhängigkeiten noch besser vermeiden.

herbivore

Hallo!

Ich benutze für alle meine Programme ebenfalls eine eigene Logging-Komponente.
Diese baut auf einem Interface auf, für welches dann verschiedene Implementierungen existieren, die auch kombinierbar sind. So kann ich später bei Bedarf z.B. für NLog einfach einen kleinen Wrapper schreiben und schon hab' ich NLog zusätzlich mit im Programm.

Der Grundgedanke war dabei, erstmal eine kleine Protokoll-Komponente zu haben, welche die grundlegenden Logging-Funktionen bereitstellt, ohne Anhängigkeiten zu anderen externen Komponenten.

Wir in der Firma haben einen 'Wrapper' um Log4Net herum gebaut
Ähnlich wie von FZelle beschrieben.
Allerdings haben wir festgestellt, dass wir mit an Sicherheit grenzender Wahrscheinlichkeit den Logger nie austauschen werden und diesen Gedanken würde ich Dir auch ans Herz legen.
Tauscht man wirklich einen Logger so oft aus, dass man einen Wrapper benötigt?

Hallo!

Tauscht man wirklich einen Logger so oft aus, dass man einen Wrapper benötigt?

Gegenfrage: Ist der dann auftretende Aufwand vertretbar, wenn man - aus welchen Gründen auch immer - den Logger doch mal wechseln muss.

Prinzipiell würde ich auch sagen, dass man den Logger vermutlich nur äusserst selten wechselt. Aber warum sich nicht einmal kurz die Mühe für einen kleinen Wrapper machen, und danach mit der Sicherheit leben, dass man damit sehr viel flexibler ist.

Der Vollständigkeit halber möchte ich mal Common.Logging einwerfen, was im Grunde ja genau der Wrapper ist, der hier gefragt ist.

You Ain´t Gonna Need It (YAGNI)

wenn man alles implementiert was man irgendwann vielleich mal benötigt, würde man nie fertig werden.
Klar wenn man nen Logger austauscht hat man dann irgendwann vielleicht mehr arbeit.
Aber wenn man sich an diese Regel hält erspart man sich in summe soviel Zeit, dass sich das widerum locker ausgeht.
Wenn ich diese Regel nicht beachten würde, würde ich noch immer am ORMapper programmieren und nicht den SmartClientLayer.
Aber Vorsicht, sich darüber Gedanken zu machen hat keiner verboten, also nicht unötig den Weg verbauen.