Abstraktion der .NET-Protokollierung mit Common Infrastructure Libraries:

Question

Ich habe kürzlich erwogen, meine Protokollierung über die Anwendung zu abstrahieren. Eine spezifischere Post auf einer anderen Ressource führte zur Empfehlung der „Common Infrastructure Libraries“:

http://netcommon.sourceforge.net/

Insbesondere die Common.Logging-Klasse, die eine gemeinsame Schnittstelle zur Verfügung, die vor einer Reihe von sitzen Logging-Implementierungen (wie log4net).

Ich bin ein wenig verabscheut, um ein weiteres Stück Code von Drittanbietern in mein Projekt einzuführen.

Hat jemand diese Bibliothek benutzt? Ich würde gerne Ihre Erfahrungen hören.

Danke

Answer 1

Werden Sie zwischen den erwähnten Protokollierungsprojekten wechseln?

Verteilen Sie die Quelle an jemanden, der eines der aufgelisteten Protokollierungsprojekte verwendet, die Sie nicht verwenden?

1. Es gibt viele weitere Protokollierung Projekte als die unterstützten diejenigen von Common.Logging
2. Dieses viel zu sein scheint wie ODBC Jahren habe vor. Es wird als austauschbar verkauft, aber sobald Sie eine bestimmte Funktion verwenden, können Sie nicht mehr wechseln.
3. Wenn bei der Protokollierung etwas schief geht, müssen Sie jetzt zwei Ebenen debuggen.

Wieder; Wenn Sie keine Bibliotheken wechseln, würde ich die Common.Logging-Klasse nicht verwenden.

Answer 2

Ich habe die Common Infrastructure Library mit log4net verwendet, und es hat gut funktioniert. Ich habe es eher als log4net benutzt, weil mein Kunde den Wunsch geäußert hat, eine Möglichkeit zu haben, Microsofts Enterprise Library (EntLib) Logging zu verwenden.

Ich bin mir nicht sicher, warum Brad Bruce rät von der Verwendung dieser Abstraktionsschicht - es war ein Kinderspiel und es gab keine Probleme. IMO log4net ist anderen Dingen weit voraus, aber einige Leute wollen EntLib, nur weil es den zusätzlichen Komfortfaktor des Microsoft-Stempels hat. Durch die Verwendung der Abstraktionsschicht gebe ich meinem Klienten die Freiheit, ohne Codeänderungen oder Neukompilierung zu EntLib zu wechseln - nur eine Konfigurationsdateiänderung.

Answer 3

Als ich begann, log4net in meiner MVC-App zu verwenden, wurde ich besorgt über die enge Kopplung meiner Controller-Klassen mit der konkreten log4net-Implementierung. Es stimmt, dass das Commit zu der spezifischen Schnittstelle, die in Common.Logging definiert ist (was im Übrigen die von log4net widerspiegelt) genau das ist; Verpflichtung. Aber die Version 2.0 von Common.Logging gab mir eine sofortige Abstraktionsebene und die log4net-Schnittstelle, die sie nachahmt, ist kampfgetestet und einfach zu benutzen. Außerdem gefällt mir die Idee, verschiedene konkrete Protokollierungsimplementierungen verwenden, testen und ausprobieren zu können, indem einfach eine Referenz hinzugefügt und eine Web.config-Datei aktualisiert wird.

Alle Punkte von Bruce sind absolut gültig. Die Abstraktion kann nichts anderes als ein falsches Gefühl von Sicherheit sein, und die Entscheidung kann mich am Ende in den Hintern stecken. Trotzdem muss man manchmal nur auf der Seite der Best Practices bleiben, bis bessere Praktiken folgen. :-)

Answer 4

Als schnelle Folge ...Ich hatte heute einen Logging-Kick und habe beschlossen, Chainsaw zum Laufen zu bringen, damit ich die Protokolle meiner App in Echtzeit sehen kann. Ich konnte jedoch keinen UdpReceiver in Chainsaw arbeiten.

Die Lösung bestand darin, Chainsaw zu vergessen und NLog (über die Common.Logging-Konfigurationseinstellungen) zu aktivieren und stattdessen den NLogViewer zu verwenden. NLog und NLogViewer haben wie angekündigt zusammengearbeitet und ich kann jetzt Protokolle einsehen, wenn sie passieren. Ich konnte NLog in meine App integrieren, ohne meine Codebasis ein bisschen zu verändern. Die Auszahlung der Common.Logging Abstraktion kam viel früher, als ich jemals erwartet hätte.