Ich arbeite für eine IT-Abteilung mit ungefähr 50+ Entwicklern. 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, unseren 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 der Schwierigkeit, die generierten Protokolle zu sehen, und einige Mitarbeiter sind frustriert, dass wir Ressourcen für Infrastruktur-Sachen wie diese ausgeben, anstatt sich auf unser Geschäft zu konzentrieren und Dinge zu verwenden, die bereits existieren wie log4net oder Enterprise Logger >
Können Sie mir helfen, Gründe aufzuzählen, warum Sie nicht Ihren eigenen .net-Logger erstellen sollten.
Auch Gründe warum Sie sollten sind willkommen, einen fairen Standpunkt zu bekommen:)
Ich würde einen anderen Ansatz wählen. Wie wäre es mit der Einführung einer gemeinsamen Schnittstelle zu Ihrer eigenen Bibliothek, z. B. Common Infrastructure Libraries ( Ссылка )? 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, wechseln Sie einfach zu einem der Open-Source-Frameworks (oder sogar zu einer kommerziellen Lösung).
HTH Alex
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 verbracht haben, an den Dingen zu arbeiten, die für den Endanwender irrelevant sind, anstatt weitere Funktionen hinzuzufügen.
Von dem Job, den ich gelernt habe, konzentriere dich immer auf die Dinge, die dein 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 Personal - verwenden Sie es mit Bedacht. Erfinden Sie 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 brauchen.
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 aus meinem Unternehmen kommen.
Ich verwende eine benutzerdefinierte Protokollierungs-API, die einen Provider-Modellentwurf verwendet, der es ermöglicht, ein externes Protokollierungsframework anzuschließen. Ich habe Provider für Log4Net, EntLib und die System.Diagnostics.Trace-Protokollierer entwickelt.
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.
Ich stimme nicht mit denen überein, die Menschen überall Räder neu erfinden sehen. 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 Protokollierungs-Framework verwenden, das veraltet sein könnte (log4net vs. nlog) und Ihre Zeit damit verschwenden würde, es zu lernen, schließen Sie nicht die Option aus, Ihre eigene Protokollierung zu erstellen. Ich habe dies mit ORM-Mapping getan, für mich war es besser, einige ORM-Klassen zu bauen, als nHybernate zu lernen.
Ich schrieb meinen eigenen , weil ich dachte, dass (A) er auf einem TraceListener basiert, der eine Standard-.NET-Klasse ist und ( B) es ist wenig und einfach zu benutzen und vielleicht weil ich sowieso einen schreiben wollte.
Aber jetzt verwende ich NLog in meinen neuen Projekten und ersetze es in einigen alten!
liege 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.
Wenn Ihre Logging-Lösung besondere Anforderungen stellt, dass eine Standardlösung nicht funktioniert, könnte es vielleicht sinnvoll sein, eine benutzerdefinierte Version zu erstellen.
Wenn dies jedoch das Argument ist, könnte man auch ein Open Source-Framework herunterladen und versuchen, es anzupassen.