.Net Logger (Napisz własne vs log4net/logger przedsiębiorstwa/nlog itp.)

Question

Pracuję dla działu IT z około 50+ programistów. Kiedyś było około 100 deweloperów, ale zostało odcięte z powodu recesji.

Kiedy nasz wydział był większy, podjęto ambitne starania o utworzenie specjalnej grupy architektonicznej.

Jedną rzeczą, o której zdecydowała ta grupa, było stworzenie naszego wewnętrznego rejestratora. Sądzili, że to takie proste zadanie, że moglibyśmy wydać zasoby i sami to zrobić. Teraz mamy problemy z wydajnością i trudnościami z przeglądaniem generowanych dzienników, a niektórzy pracownicy są sfrustrowani, że wydaliśmy zasoby na takie elementy infrastruktury zamiast skupiać się na obsłudze naszej firmy i korzystaniu z rzeczy, które już istnieją, jak log4net lub Enterprise Logger.

Czy możesz mi pomóc we wskazaniu powodów, dla których powinieneś nie stworzyć swój własny rejestrator .net.

także powody dlaczego powinny są mile widziane, aby uzyskać rzetelne punkt widzenia :)

Answer 1

Chciałbym przyjąć inne podejście. Jak o pierwszym wprowadzeniu wspólnego interfejsu do własnej biblioteki, takich jak biblioteki Common Infrastructure (http://netcommon.sourceforge.net/). Następnie możesz stopniowo przenosić wszystkie projekty do tego interfejsu, a jeśli twoja własna biblioteka nie nadaje się do pracy dla dużych projektów, po prostu przełącz się do jednego z frameworków open source (lub nawet komercyjnego rozwiązania).

HTH Alex

Answer 2

jeśli takie rozwiązanie rejestrowania ma specjalne wymagania, że ​​przy rozwiązaniu półki nie działa, niż może podejmowania niestandardowa wersja może być warta zachodu.

Jeśli jest to jednak argument, można również rozważyć pobranie struktury opensource i spersonalizować ją.

Answer 3

użyć niestandardowego rejestrowania API, które wykorzystuje model dostawca design, który umożliwia rejestrowanie zewnętrzne ramy zostać podłączony. Mam opracowane dostawców dla log4net, EntLib i System.Diagnostics.Trace rejestratory.

Jest to w zasadzie ta sama koncepcja, co Common Infrastructure Libraries.

Oznacza to, że rozwój wewnętrzny nie ma wyraźnej zależności od zewnętrznej struktury rejestrowania, ale można nadal korzystać ze wszystkich funkcji swojego ulubionego mechanizmu rejestrowania. W praktyce zwykle korzystamy z Log4Net z wyjątkiem klientów, którzy już korzystają z EntLib.

Answer 4

• To kosztuje.
• To było zrobione tak wiele razy wcześniej.
• Nie jesteś tak wyjątkowy, jak myślisz. Jeśli tak, zrób coś z tym.
• Może nie jesteś tak mądry, jak myślisz.
• Czy jesteś za dużo pracowników? Jeszcze?

Answer 5

W mojej ostatniej pracy prawie cała infrastruktura została napisana przez nas, zamiast używać produktów z półki. (i przez "całą infrastrukturę" mam na myśli WSZYSTKO - rejestrowanie, przesyłanie wiadomości, bazę danych, kontenery itd.).

Jedną z największych wad tego rozwiązania było to, że spędzaliśmy większość czasu pracując nad rzeczami, które są nieistotne dla użytkownika końcowego, zamiast dodawać więcej funkcji.

z tej pracy Nauczyłem się, aby zawsze koncentrować się na rzeczach, które produkt miał rozwiązać, aby uzyskać. czy twoja firma opracowuje rejestratory? czy jakość twojego rejestratora będzie miała większy wpływ na klienta niż na inną funkcję? Nie sądzę.

Masz ograniczony budżet i siłę roboczą - używaj go mądrze. Nie wymyślaj ponownie koła. Jestem pewna, że ​​Twoja firma i klienci skorzystają, jeśli skupisz uwagę na rzeczach, których potrzebują.

w moim bieżącym projekcie Używam NHibernate jako struktury ORM zamiast wewnętrznego, który jest używany w innych projektach. zamiast naprawiać błędy w starym środowisku ORM, skupiam się na głównej mapie drogowej projektu. Co więcej, NHibernate ma swoją własną mapę drogową, co oznacza, że ​​dodatkowe funkcje będą dostępne bez większych zasobów z mojej firmy.

Answer 6

Nie zgadzam się z tymi, którzy widzą ludzi wymyślających wszędzie koła. Koło może być serwerem baz danych, systemem operacyjnym lub językiem programowania. Jednak rzeczy takie jak struktura ORM lub rzecz log4net nie są na rynku wystarczająco długo, aby uznać je za koła. Wiele z tych produktów ma krótki cykl życia, są one zastępowane nowymi podejściami, po prostu zastanów się, ile szkieletów ORM widziałeś, a następnie pojawia się Microsoft i uruchamia LINQ. Logowanie nie jest solidną dyscypliną, której możesz się nauczyć i zależy to od platformy. Biorąc pod uwagę wykorzystanie struktury rejestrowania, która mogłaby stać się przestarzała (log4net vs nlog), marnowanie czasu na jej naukę nie wyklucza możliwości tworzenia własnych rejestrów. Zrobiłem to z mapowaniem ORM, dla mnie lepiej było budować kilka klas ORM niż uczyć się nHybernate.

Answer 7

Napisałem mój own one ponieważ myślałem (A) opiera się na TraceListener, który jest standardową klasą .NET i (B) jest mały i prosty w użyciu, a może dlatego, że chciałem napisać tak.

Ale teraz używam NLog w moich nowych projektach i zastępuję go w niektórych starych!

Czy jestem w błędzie? Oba działa dla mnie dobrze, a powodem używania NLog dla mnie było to, że chciałem funkcji wymagającej niemal przepisania mojego niestandardowego TraceListener. Okazało się, że samouczek trwający 1 lub 2 godziny z przykładową aplikacją był dla mnie tańszy. To nie jest uniwersalna sytuacja; ale pomaga uzyskać bardziej przejrzysty obraz problemów z rejestrowaniem.