Al mirar la documentación de log4net, ¿puede averiguar cómo obtener sus datos personalizados registrados en un archivo? Si es así, también debería poder obtener esos mismos datos registrados en la base de datos. Solo agregue más columnas en su tabla, más columnas en el nodo <command text> de AdoNetAppender, y más nodos <parameter>.
Creo que tendrá algo de trabajo para hacer que sus parámetros entrantes y salientes sean registrados. ¿Los necesita registrados en columnas separadas (probablemente no sean fáciles de limpiar)? ¿Está bien si se registran junto con el mensaje?
Por ejemplo, si usted tiene el siguiente método que desea poner ingresando a:
public void DoSomething(int x, int y)
{
log.Info("Inside DoSomething");
}
¿Qué desea obtener la salida para parecerse? ¿Desea que la información log4net "estándar" aparezca en columnas separadas (marca de tiempo, nombre del registrador, nivel, mensaje)? ¿Y los parámetros? En caso de que x e y aparecer en columnas separadas (probablemente no es muy fácil de hacer a menos que cada método tiene el mismo número de parámetros) o sería ok si los parámetros se registran como esto:
public void DoSomething(int x, int y)
{
ILog log = LogManager.GetLogger("abc");
log.InfoFormat("Parameters: x = {0}, y = {1}", x, y);
log.Info("Inside DoSomething");
}
Las declaraciones de registro generará mensajes se verá algo como esto:
11/29/2010 16:36:00 | abc | INFO | Parameters: x = 10, y = 20
11/29/2010 16:36:00 | abc | INFO | Inside DoSomething
He utilizado | carácter para mostrar lo que serían los campos con un diseño de patrón que muestra la marca de tiempo, el nombre del registrador, el nivel de registro y el mensaje.
Ver una solución de AOP como PostSharp podría ayudarlo porque podría agregar de manera relativamente fácil el registro de entrada/salida sin "contaminar" el código fuente de su aplicación con las declaraciones de registro. Dentro del "aspecto" de registro, usted tendría acceso a los parámetros del método.
Me podría estar faltando algo, pero sospecho que si desea mantener sus parámetros de método como columnas individuales en la base de datos, entonces le resultará difícil hacerlo. Si está satisfecho con la combinación de todos los parámetros (manualmente) para cada método como una sola columna (esencialmente una cadena formateada), entonces será más fácil.Un precio que tendrá que pagar es que tendrá que registrar explícitamente todos los parámetros (a menos que vaya por la ruta AOP).
Si está considerando usar log4net, también debería considerar usar NLog. No necesariamente lo ayudará con los problemas que describí anteriormente, pero creo que es un competidor digno de log4net.
[EDIT]
Para obtener el "nombre del componente" registrado por log4net, debe asignar nombres a los registradores para sus componentes. Cuando llama a LogManager.GetLogger (nombre), puede pasar cualquier nombre (o tipo). Un patrón común es tener un código como éste en cada clase:
public class MyClass
{
private static readonly ILog logger = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
public void DoSomething(int x)
{
logger.InfoFormat("Inside DoSomething. x = {0}", x);
}
}
Esto hará que un registrador de llamada con el nombre de clase completo (espacio de nombre + nombre de la clase). Si haces esto en todas las clases, entonces puedes controlar el registro (nivel, a qué apéndice va, etc.) por clase. Por lo tanto, podría convertir fácilmente el registro para Class1 en Info y el registro para Class2 Off, etc. Esto le da el potencial para el mayor grado de control de su registro.
Ahora, en su archivo de configuración, no está obligado a enumerar cada registrador (es decir, cada nombre de clase completamente calificado) explícitamente. Podrías simplemente configurar el registrador de raíz y luego esa configuración se aplicaría a cada registrador. Podrías controlar tu registro por espacio de nombres. Por ejemplo, si usted trabaja para CompanyX y tiene reglas de espacio de nombres explícitos, los espacios de nombres podrían ser:
CompanyX
CompanyX.DataAccess
CompanyX.DataAccess.Read
CompanyX.DataAccess.Write
CompanyX.GUI
CompanyX.Forms
CompanyX.Controls
Dentro de cada espacio de nombres, es posible que tenga varias clases (al igual que varios lectores de datos diferentes, clases de ayuda, escritores de datos, etc.) Con sus clases organizadas de esta manera y con sus clases obteniendo registradores como se indicó anteriormente, podría configurar fácilmente el registro para todas las clases en CompanyX, o todos los registradores en CompanyX.DataAccess, o CompanyX.DataAccess.Read, etc. Incluso podría desactivar todo el inicio de sesión , pero enciéndelo para esa clase problemática que te está dando problemas.
También puede obtener sus registradores por nombres arbitrarios (es decir, no tiene que usar el nombre de clase si no desea). Se podría definir áreas funcionales en su aplicación (s) y obtener madereros sobre la base de que:
ILog logger = LogManager.GetLogger("DataAccess");
ILog logger = LogManager.GetLogger("Performance");
ILog logger = LogManager.GetLogger("UI");
Y así sucesivamente. No veo que esto proporcione muchos beneficios con respecto al uso del nombre de clase completo. Si su (s) espacio (s) de nombre están bien organizados, entonces su capacidad para configurar su registro tendrá la máxima flexibilidad con el mínimo esfuerzo de su parte.
Otra palabra en NLog ... NLog es muy similar a log4net. Se tiene la característica útil de ser capaz de devolver automáticamente un registrador para la clase actual:
Logger logger = NLog.LogManager.GetCurrentClassLogger();
Esto ahorra al menos algo de tecleo de su parte. NLog también acaba de lanzar una nueva versión (actualmente en versión beta).
No sé si algo de esto ayudó, ¡pero espero que sí!
¡Buena suerte!
Está bien tener todos los parámetros en 1 campo, pero (como mencioné en el comentario a otra respuesta) me gustaría tener el nombre del componente en una columna separada (sin cambiar el contexto global para cada llamada). También me gustaría tener 3 columnas adicionales: income_data, outcome_data, error_message. Probablemente, podría configurar pocas instancias de registrador diferentes (1 por componente)? ¿Y en este caso no necesitaré cambiar la configuración global cada vez? Lo siento, soy nuevo con log4net. – Budda
Sí, es probable que desee tener al menos un registrador por componente. He agregado algunos ejemplos en mi respuesta. – wageoghe