.Net Logger (Escriba el suyo frente a log4net/enterprise logger/nlog, etc.)

Question

Trabajo para un departamento de TI con más de 50 desarrolladores. Solía ​​haber más de 100 desarrolladores, pero fue cortado debido a la recesión.

Cuando nuestro departamento era más grande hubo un esfuerzo ambicioso para configurar un grupo de arquitectura especial.

Una cosa que este grupo decidió hacer fue crear nuestro propio registrador interno. Pensaron que era una tarea tan simple que podríamos gastar recursos y hacerlo nosotros mismos. Ahora estamos teniendo problemas con el rendimiento y la dificultad para ver los registros generados y algunos empleados se sienten frustrados por el hecho de que gastemos recursos en infraestructura como esta en lugar de centrarnos en prestar servicios a nuestra empresa y utilizar cosas que ya existen como log4net o Enterprise Logger.

Puede ayudarme en el listado de las razones por las que debe no crear su propio registrador .net.

también razones de por qué usted debe son bienvenidos para obtener un punto de vista justo :)

Answer 1

Tomaría un enfoque diferente. ¿Qué hay de la introducción inicial de una interfaz común a su propia biblioteca, como Bibliotecas de infraestructura común (http://netcommon.sourceforge.net/). Luego puede mover gradualmente todos los proyectos a esa interfaz y si su propia biblioteca no está preparada para grandes proyectos, simplemente cambie a uno de los marcos de código abierto (o incluso una solución comercial).

HTH Alex

Answer 2

si su solución de registro tiene tales requisitos especiales que un fuera de la solución de plataforma no funciona, que tal vez haciendo una la versión personalizada puede valer la pena.

Si este es el argumento, también se podría considerar descargar un marco de código abierto e intentar personalizarlo.

Answer 3

utilizo una API de registro personalizado que utiliza un diseño de modelo de proveedor, que permite a un marco de registro externo para ser enchufado. He desarrollado proveedores de Log4net, EntLib y la System.Diagnostics.Trace madereros.

Este es esencialmente el mismo concepto que el Common Infrastructure Libraries.

Esto significa que los desarrollos internos no tienen una dependencia explícita en un marco de trabajo de registro externo, pero aún puede beneficiarse de todas las características de su marco de trabajo de registro favorito. En la práctica, usamos Log4Net, a excepción de los clientes que ya están usando EntLib.

Answer 4

• Cost a money.
• Se hizo tantas veces antes.
• No eres tan especial como crees. Si es así, entonces haga algo al respecto.
• Quizás no sea tan listo como cree.
• ¿Tiene exceso de personal? ¿Todavía?

Answer 5

En mi último trabajo, casi toda la infraestructura fue escrito por nosotros en lugar de utilizar algunos productos de de la plataforma. (y por "toda la infraestructura" me refiero a TODO - Logging, Messaging, Database, Containers de etc.).

Una de las mayores desventajas de esto es que nos hizo pasar la mayor parte de nuestro tiempo trabajando en cosas que son irrelevantes para el usuario final en lugar de agregar más funciones.

de ese trabajo que he aprendido a siempre se centran en las cosas que su producto debe resolver. ¿Está su empresa desarrollando madereros? ¿La calidad de su registrador influirá en su cliente más que en otra característica? No lo creo.

Tiene un presupuesto y personal limitados: úselo sabiamente. No reinventar la rueda. Estoy seguro de que su empresa y sus clientes se beneficiarán si enfoca su atención en las cosas que necesitan.

en mi proyecto actual Estoy utilizando NHibernate como marco ORM en lugar de uno interno que está en uso en otros proyectos. en lugar de corregir errores en el antiguo marco ORM, mi atención se centra en la hoja de ruta principal del proyecto. Además, NHibernate tiene su propia hoja de ruta, lo que significa que las funciones adicionales vendrán sin muchos recursos de mi empresa.

Answer 6

No estoy de acuerdo con quienes ven a las personas reinventando ruedas en todas partes. Una rueda podría ser un servidor de base de datos, un sistema operativo o un lenguaje de programación. Sin embargo, cosas como un marco de ORM o esta cosa de log4net no están en el mercado el tiempo suficiente para ser consideradas ruedas. Muchos de estos productos tienen un ciclo de vida corto, son reemplazados por nuevos enfoques, solo considere cuántos marcos ORM ha visto, y luego viene Microsoft y lanza LINQ. El registro no es una disciplina sólida que pueda aprender y depende de la plataforma. Por lo tanto, considerar el uso de un marco de trabajo de registro que podría quedar obsoleto (log4net vs nlog), perder el tiempo aprendiéndolo, no excluye la opción de crear su propio registro. He hecho esto con el mapeo ORM, para mí ha sido mejor construir algunas clases ORM que aprender nHybernate.

Answer 7

Escribí mi own one porque pensé que (A) se basa en un TraceListener que es una clase .NET estándar y (B) es pequeño y simple de usar y tal vez porque quería escribir uno de todos modos.

¡Pero ahora estoy usando NLog en mis nuevos proyectos y lo estoy reemplazando en algunos viejos!

¿Estoy equivocado? Ambos funcionan bien para mí y la razón por la que utilicé NLog fue que quería una característica que necesitaba casi una reescritura de mi TraceListener personalizado. Resultó que un tutorial de 1 o 2 horas con una aplicación de muestra era más barato para mí. Esta no es una situación universal; pero ayuda a tener una imagen más clara sobre los problemas de registro.