A menudo en el proyecto hay un error incomprensible para el cual es necesario el
registro máximo de todas las consultas a la Base de Datos. El artículo ayudará a aquellos que escriben (implementan en el servidor) uno de sus primeros proyectos en
Asp.Net Boilerplate .
Este artículo está escrito para aquellos nuevos en la tecnología Asp.Net Boilerplate que han encontrado algún error extraño relacionado con la Base de Datos. Cuando se usa PostgreSQL, este puede ser, por ejemplo, el primer proyecto. La motivación para escribir el artículo fue que la solución a esta pregunta no es tan fácil de encontrar en Internet, incluso en inglés, sin mencionar el hecho de que las soluciones encontradas no responden completamente a todas las preguntas sobre este problema.
Versión del producto: Asp.Net Boilerplate 4.3, .NET Core 2.1
Si completa estos pasos : En su archivo de registro principal, verá todas las solicitudes a la Base de datos iniciada sesión.
Paso 1
Debes crear un registrador. Ya hay un registrador interno configurado en la plataforma Boilerplate. Puede ser Log4Net como estándar. No hay necesidad de hacer ninguna manipulación con él. En cambio, es suficiente crear una clase de registrador que registre como procesador de todos los mensajes de registro de la Base de datos.
Paso 1.1
Proyecto * .EntityFrameworkCore. Aquí necesitamos crear 2 clases. Por un lado, un registrador que solo hará una cosa es enviar todos los mensajes de la base de datos al registro del sistema. Llamémoslo
MyLogger. Y el proveedor de este registrador que creará MyLogger. El proveedor se llama
MyLoggerProvider.Creamos un archivo con el siguiente código (un archivo para simplificar, aunque, por supuesto, cada archivo debe tener una clase):
public class MyLoggerProvider : ILoggerProvider { private Castle.Core.Logging.ILogger _logger; public MyLoggerProvider(Castle.Core.Logging.ILogger logger) { _logger = logger; } public ILogger CreateLogger(string categoryName) { return new MyLogger(_logger); } public void Dispose() { } } public class MyLogger : ILogger { private Castle.Core.Logging.ILogger _logger; public MyLogger(Castle.Core.Logging.ILogger logger) { _logger = logger; } public IDisposable BeginScope<TState>(TState state) { return null; } public bool IsEnabled(LogLevel logLevel) { return true; } public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter) { if (IsEnabled(logLevel)) { var msg = formatter(state, exception); _logger.Info("DB-REQUEST: " + msg); } } }
Si observa detenidamente, puede ver cómo se reenvía algún otro registrador a MyLoggerProvider y luego a MyLogger. Resulta que ya es el tercero! La conclusión es que este tercero es la clase del nivel de la infraestructura de registro, que debe obtenerse de las entrañas del Boilerplate con la ayuda de la cual los mensajes se guardarán en el registro. Ver abajo.
Paso 2
Dentro del marco del mismo proyecto * .EntityFrameworkCore, vaya al archivo * DbContextConfigurer.cs y realice los siguientes cambios en ambos métodos Configure ():
2.1) Agregue un parámetro loggerfactory de tipo LoggerFactory
2.2) Agregue dos líneas al cuerpo del método:
builder.UseLoggerFactory(loggerFactory); builder.EnableSensitiveDataLogging(true);
El significado de
UseLoggerFactory es habilitar el uso de loggerFactory, que se pasa en los parámetros para registrar la Base de datos. Es muy importante recordar que aquí habilitamos el registro de la base de datos.
El significado de
EnableSensitiveDataLogging es habilitar el registro no solo de las consultas de la base de datos, sino también registrar todos los datos en estas consultas. Sin esta configuración, no podrá ver los datos en las consultas; serán reemplazados por signos de interrogación.
Paso 3
Dentro del marco del mismo proyecto * .EntityFrameworkCore, vamos al archivo * DbContextFactory.cs.
3.1) Agregar un nuevo método:
private LoggerFactory GetDbLoggerFactory() { return new LoggerFactory(new[] { new MyLoggerProvider(NullLogger.Instance) }); }
3.2) En el método CreateDbContext ():
Porque Como previamente agregamos un nuevo parámetro a ambas implementaciones Configure (), aquí debería mostrarse un error. Es hora de especificar este nuevo parámetro: registramos GetDbLoggerFactory () con una coma. Es decir el nuevo método de la cláusula 3.1 devolverá el valor del nuevo parámetro loggerFactory.
Paso 4
En el marco del mismo proyecto * .EntityFrameworkCore, vamos al archivo * EntityFrameworkModule.cs.
4.1) Agregar un nuevo método:
private LoggerFactory GetDbLoggerFactory() { return new LoggerFactory(new[] { new MyLoggerProvider(Logger) }); }
4.2) En el método PreInitialize ():
Porque Como previamente agregamos un nuevo parámetro a ambas implementaciones de Configure (), también debería mostrarse un error aquí. Especificamos un nuevo parámetro similar a la Sección 3.2: registramos GetDbLoggerFactory () con una coma. Es decir el nuevo método de la cláusula 4.1 devolverá el valor del nuevo parámetro loggerFactory.
Resultado
En el archivo de registro principal (de manera predeterminada, Logs.txt) verá todas las consultas precedidas por la secuencia de caracteres DB-REQUEST (es a partir de esto que puede buscar datos en el registro).
Comprensión general de la solución.
Entonces, ahora explicaré lo que hemos hecho. Se da una explicación al final del artículo, porque a menudo los lectores están interesados en comenzar a hacer algo específico ya.
En la clase * DbContextFactory, así como * EntityFrameworkModule, creamos nuestro LoggerFactory, en cuyos parámetros especificamos el MyLoggerProvider creado. Pero como clase de infraestructura que registrará directamente en el primer caso (* DbContextFactory), pasamos el código auxiliar NullLogger.Instance para que no haya entradas. En el segundo caso (* EntityFrameworkModule) pasamos el registrador, que ya está en el módulo Abp. Este es el campo Logger. Ya está inicializado y se puede iniciar sesión con él. En consecuencia, nuestro MyLogger podrá escribir en el archivo Logs.txt utilizando esta clase.
Toda la lógica es que esta fábrica de loggerFactory está instalada como una fábrica de registros para trabajar con la base de datos. Tan pronto como se necesita un registrador, lo crea la fábrica. Y este es nuestro MyLogger, que, a su vez, registra todo lo que viene a Logs.txt (o la fuente en la que está configurada la salida de sus registros principales).
Como puede ver, no todo es tan simple y los niveles de abstracciones a veces se congelan, ¡especialmente para principiantes! Haz tus preguntas en los comentarios.
Nota:- La solución se creó para encender el registrador, comprender cuál es el error y apagarlo. No está diseñado para uso a largo plazo.