.Net Logger (Scrivete il vostro log4net/logger/nlog ecc.)

Question

Lavoro per un reparto IT con circa 50 sviluppatori. Un tempo erano circa 100 sviluppatori, ma è stato tagliato a causa della recessione.

Quando il nostro dipartimento era più grande, c'era uno sforzo ambizioso per creare un gruppo speciale di architettura.

Una cosa che questo gruppo ha deciso di fare è stata creare il nostro logger interno. Pensavano che fosse un compito così semplice da poter spendere le risorse e farlo da soli. Ora abbiamo problemi con le prestazioni e la difficoltà di visualizzare i registri generati e alcuni dipendenti sono frustrati dal fatto che stiamo spendendo risorse su infrastrutture come questa invece di concentrarsi sul servizio della nostra azienda e sull'utilizzo di cose già esistenti come log4net o Enterprise Logger.

Puoi aiutarmi a elencare i motivi per cui dovresti non creare il tuo .net logger.

anche ragioni per cui si dovrebbe sono invitati a ottenere un punto di vista giusto :)

Answer 1

Vorrei adottare un approccio diverso. Che ne dici di introdurre per la prima volta un'interfaccia comune alla tua libreria come le Common Infrastructure Libraries (http://netcommon.sourceforge.net/). Quindi è possibile spostare gradualmente tutti i progetti su tale interfaccia e se la propria libreria non è all'altezza del lavoro per progetti di grandi dimensioni, passare semplicemente a uno dei framework open source (o anche a una soluzione commerciale).

HTH Alex

Answer 2

Se la soluzione di registrazione ha tali requisiti particolari che un off la soluzione shelf non funziona, forse di fare un la versione personalizzata potrebbe essere utile.

Se questo è l'argomento, si potrebbe anche considerare di scaricare un framework opensource e provare a personalizzarlo.

Answer 3

io uso un log API personalizzata che utilizza un design modello di provider, che consente a un quadro di registrazione esterno per essere inserita. Ho sviluppato provider per Log4Net, EntLib e lo System.Diagnostics.Trace logger.

Questo è essenzialmente lo stesso concetto di Common Infrastructure Libraries.

Ciò significa che gli sviluppi interni non hanno una dipendenza esplicita da un framework di registrazione esterno, tuttavia è comunque possibile beneficiare di tutte le funzionalità del framework di registrazione preferito. In pratica usiamo Log4Net, ad eccezione dei clienti che già utilizzano EntLib.

Answer 4

• Costa denaro.
• E 'stato fatto così tanto tempo prima.
• Non sei così speciale come pensi. Se lo sei, quindi fare qualcosa al riguardo.
• Forse non sei intelligente come pensi.
• Sei finito? Ancora?

Answer 5

Nel mio ultimo lavoro, quasi tutte le infrastrutture sono state scritte da noi invece di utilizzare alcuni prodotti standard. (e per "tutta l'infrastruttura" intendo TUTTO - Registrazione, messaggistica, database, contenitori di così via).

Uno dei maggiori svantaggi è che ci ha fatto passare la maggior parte del nostro tempo a lavorare su cose che sono irrilevanti per l'utente finale invece di aggiungere più funzionalità.

da quel lavoro ho imparato a concentrarsi sempre sulle cose che il prodotto avrebbe dovuto risolvere. la tua azienda sta sviluppando i taglialegna? la qualità del tuo logger influenzerà il tuo cliente più di un'altra caratteristica? Io non la penso così

Hai un budget e una manodopera limitati: usalo saggiamente. Non reinventare la ruota. Sono sicuro che la vostra azienda e i vostri clienti ne trarranno beneficio se focalizzerete la vostra attenzione sulle cose di cui hanno bisogno.

nel mio progetto corrente sto usando NHibernate come quadro ORM invece di uno interno che è in uso in altri progetti. invece di correggere i bug nel vecchio framework ORM, il mio focus è sulla roadmap principale del progetto. inoltre, NHibernate ha la propria roadmap, il che significa che saranno disponibili ulteriori funzionalità senza molte risorse dalla mia azienda.

Answer 6

Non sono d'accordo con coloro che vedono persone che reinventano ruote dappertutto. Una ruota potrebbe essere un server di database, un sistema operativo o un linguaggio di programmazione. Tuttavia cose come una struttura ORM o questa cosa di log4net non sono sul mercato abbastanza tempo per essere considerate ruote. Molti di questi prodotti hanno un breve ciclo di vita, vengono sostituiti da nuovi approcci, basta considerare quanti quadri ORM avete visto, quindi arriva Microsoft e lancia LINQ. La registrazione non è una disciplina solida che puoi imparare ed è molto dipendente dalla piattaforma. Quindi, considerando l'utilizzo di un framework di registrazione che potrebbe diventare obsoleto (log4net vs nlog), sprecare tempo a impararlo, non esclude l'opzione di creare il proprio log. L'ho fatto con la mappatura ORM, per me è stato meglio costruire alcune classi ORM rispetto all'apprendimento di nHybernate.

Answer 7

Ho scritto il mio own one perché ho pensato (A) che sia basato su un TraceListener che è una classe .NET standard e (B) è poco e semplice da usare e forse perché volevo scriverne uno comunque.

Ma ora sto usando NLog nei miei nuovi progetti e lo sostituisco in alcuni vecchi!

Mi sbaglio? Entrambi funzionano per me e il motivo dell'utilizzo di NLog per me è che volevo una funzionalità che richiedesse quasi la riscrittura del mio TraceListener personalizzato. Si è scoperto che un tutorial di 1 o 2 ore con un'app campione era più economico per me. Questa non è una situazione universale; ma aiuta ad avere un'immagine più chiara dei problemi di registrazione.