.Net Logger (Schreiben Sie Ihre eigenen vs log4net/Enterprise Logger/Nlog usw.)

Question

Ich arbeite für eine IT-Abteilung mit über 50 Entwickler. Früher waren es über 100 Entwickler, aber wegen der Rezession wurde es gekürzt.

Als unsere Abteilung größer war, wurden ehrgeizige Anstrengungen unternommen, um eine spezielle Architekturgruppe zu gründen.

Eine Sache, die diese Gruppe beschlossen hat, war unsere eigenen internen Logger zu erstellen. Sie dachten, es wäre eine so einfache Aufgabe, dass wir Ressourcen ausgeben und es selbst tun könnten. Jetzt haben wir Probleme mit der Leistung und den Schwierigkeiten, die generierten Protokolle zu sehen, und einige Mitarbeiter sind frustriert, dass wir Ressourcen für Infrastruktur-Sachen wie diese ausgeben, anstatt uns auf unser Geschäft zu konzentrieren und bereits existierende Dinge wie log4net oder Enterprise Logger zu verwenden.

Können Sie mir bei der Auflistung Gründe helfen, warum Sie sollten nicht erstellen Sie Ihre eigenen .net-Logger.

auch Gründe, warum Sie sollen sind willkommen eine faire Sicht zu bekommen :)

Answer 1

Ich würde einen anderen Ansatz nehmen. Wie wäre es mit der Einführung einer gemeinsamen Schnittstelle zu Ihrer eigenen Bibliothek, z. B. Common Infrastructure Libraries (http://netcommon.sourceforge.net/)? Dann können Sie alle Projekte nach und nach auf diese Oberfläche verschieben und wenn Ihre eigene Bibliothek nicht für große Projekte geeignet ist, dann wechseln Sie einfach zu einem der Open-Source-Frameworks (oder sogar zu einer kommerziellen Lösung).

HTH Alex

Answer 2

wenn Ihre Logging-Lösung so spezielle Anforderungen hat, die eine aus dem Regal Lösung nicht funktioniert, als vielleicht ein zu machen benutzerdefinierte Version könnte sich lohnen.

Wenn dies das Argument ist, könnte man auch in Erwägung ziehen, ein Opensource-Framework herunterzuladen und zu versuchen, es anzupassen.

Answer 3

ich ein benutzerdefiniertes Logging-API verwenden, die ein Provider-Modell zum Einsatz, die ein externes Logging-Framework ermöglicht es, angeschlossen werden. Ich habe entwickelt Anbieter für Log4Net, EntLib und die System.Diagnostics.Trace Holzfäller.

Dies ist im Wesentlichen das gleiche Konzept wie die Common Infrastructure Libraries.

Dies bedeutet, dass interne Entwicklungen nicht explizit von einem externen Protokollierungs-Framework abhängig sind. Sie können dennoch von allen Funktionen Ihres bevorzugten Protokollierungs-Frameworks profitieren. In der Praxis verwenden wir normalerweise Log4Net, außer für Kunden, die bereits EntLib verwenden.

Answer 4

• Es kostet Geld.
• Es war so viele Zeit zuvor.
• Sie sind nicht so speziell wie Sie denken. Wenn Sie sind, dann tun Sie etwas dagegen.
• Vielleicht sind Sie nicht so schlau wie Sie denken.
• Sind Sie überbesetzt? Noch?

Answer 5

In meinem letzten Job wurde fast die gesamte Infrastruktur von uns geschrieben, anstatt einige Standardprodukte zu verwenden. (Und durch "die ganze Infrastruktur" meine ich ALLES - Logging, Messaging, Datenbank, Container usw.).

Einer der größten Nachteile war, dass wir die meiste Zeit damit verbrachten, an den Dingen zu arbeiten, die für den Endanwender irrelevant sind, anstatt mehr Funktionen hinzuzufügen.

von diesem Job habe ich gelernt, immer konzentrieren sich auf die Dinge, die Ihr Produkt lösen sollte. Entwickelt Ihre Firma Holzfäller? Wird die Qualität Ihres Loggers Ihren Kunden mehr beeinflussen als ein anderes Feature? Ich denke nicht.

Sie haben ein begrenztes Budget und Manpower - verwenden Sie es mit Bedacht. Erfinde das Rad nicht neu. Ich bin mir sicher, dass Ihr Unternehmen und Ihre Kunden davon profitieren werden, wenn Sie Ihre Aufmerksamkeit auf die Dinge richten, die sie benötigen.

In meinem aktuellen Projekt verwende ich NHibernate als ORM-Framework anstelle eines internen, das in anderen Projekten verwendet wird. Anstatt Fehler im alten ORM-Framework zu beheben, konzentriere ich mich auf die Haupt-Roadmap des Projekts. Darüber hinaus verfügt NHibernate über eine eigene Roadmap, was bedeutet, dass zusätzliche Funktionen ohne große Ressourcen von meinem Unternehmen kommen.

Answer 6

Ich stimme nicht mit denen überein, die Leute sehen, die überall Räder neu erfinden. Ein Rad könnte ein Datenbankserver, ein Betriebssystem oder eine Programmiersprache sein. Allerdings sind Dinge wie ein ORM-Framework oder diese log4net-Sache nicht auf dem Markt genug, um als Räder zu gelten. Viele dieser Produkte haben einen kurzen Lebenszyklus, sie werden durch neue Ansätze ersetzt, denken Sie nur daran, wie viele ORM-Frameworks Sie gesehen haben, und dann kommt Microsoft und startet LINQ. Logging ist keine solide Disziplin, die Sie lernen können und es ist sehr plattformabhängig. Wenn Sie also ein Protokollierungsframework verwenden, das veraltet sein könnte (log4net vs. nlog), verschwenden Sie nicht Ihre Zeit, es zu lernen. Ich habe dies mit ORM-Mapping getan, für mich war es besser, ein paar ORM-Klassen zu bauen, als nHybernate zu lernen.

Answer 7

Ich schrieb meine own one, weil ich dachte (A) es basiert auf einem TraceListener, der eine Standard-.NET-Klasse ist und (B) es ist klein und einfach zu bedienen und vielleicht, weil ich einen trotzdem schreiben wollte.

Aber jetzt benutze ich NLog in meinen neuen Projekten und ersetze es in einigen alten!

Bin ich falsch? Beides funktioniert für mich gut und der Grund für die Verwendung von NLog für mich war, dass ich ein Feature wollte, das ein fast neues Schreiben meines benutzerdefinierten TraceListeners benötigte. Es stellte sich heraus, dass ein 1- oder 2-stündiges Tutorial mit einer Beispiel-App für mich günstiger war. Dies ist keine universelle Situation; aber hilft mit einem klareren Bild über Protokollierungsprobleme.