Recabamos en todo el mundo online para de este modo mostrarte la respuesta a tu dilema, si continúas con alguna inquietud deja la inquietud y te responderemos con gusto.
Solución:
Con respecto al uso de registro en cualquier componente:
La adición de registro a un componente en su aplicación se realiza solicitando un
ILoggerFactoryo unILoggervía inyección de dependencia. Si unaILoggerFactoryse solicita, se debe crear un registrador utilizando suCreateLoggermétodo.
Si tu CustomClass es un contenedor de datos (clase DTO), no debería saber sobre el registro, solo contener datos.
Para otras clases con nombres como “Servicio”, “Proveedor”, “Controlador”, etc., las mejores prácticas son resolver instancias mediante inyección de dependencia. En general, debe usar DI siempre que sea posible, ya que es una técnica para lograr un acoplamiento flexible entre los objetos y sus colaboradores o dependencias. Para obtener más información, la siguiente pregunta puede ser interesante: ¿Debo usar Dependency Injection o static ¿suerte?
Así que simplemente agrega ILogger a su constructor (en realidad, de la misma manera que lo hace para los controladores), ya que .NET Core solo admite la inyección de constructor de forma predeterminada:
public class CustomClass
private readonly ILogger _logger;
public CustomClass(ILogger logger)
_logger = logger;
El contenedor de inyección de dependencias integrado de ASP.NET Core resolverá automáticamente las dependencias transitorias. Entonces, si tu controlador tiene clase A como una dependencia que usa clase B donde desea registrar algo, su código puede ser algo como esto:
public class MyController
public MyController(ClassA classA)
...
public class ClassA
public ClassA(ClassB classB)
...
public class ClassB
private readonly ILogger _logger;
public ClassB(ILogger logger)
_logger = logger;
public void DoSomethingWithLogging()
// use _logger
Tenga en cuenta que también debe registrar las dependencias en Startup utilizando IServiceCollection.Add… métodos:
public void ConfigureServices(IServiceCollection services)
// ...
services.AddTransient();
services.AddTransient();
El soporte de registro integrado significa que .NET Core de fábrica conoce y utiliza abstracciones integradas para el registro. Esto se hace principalmente por ILoggerFactory y ILoggerProvider interfaces.
///
/// Represents a type used to configure the logging system and create instances of
public interface ILoggerFactory : IDisposable
//
/// Represents a type that can create instances of
public interface ILoggerProvider : IDisposable
Usando el tuyo ILoggerProvider implementación, puede agregar su propio registrador que puede hacer lo que quiera. Puede verificar la implementación del registrador NLog como ejemplo de trabajo.
Y gracias a ILoggerFactory, simplemente puede configurar su registrador para propósitos específicos del proyecto:
Para configurar el registro en su aplicación ASP.NET Core, debe resolver
ILoggerFactoryen elConfiguremétodo de tuStartupclase. ASP.NET Core proporcionará automáticamente una instancia deILoggerFactoryutilizando la inyección de dependencia cuando agrega un parámetro de este tipo a laConfiguremétodo.
Este artículo indica que debe usar DI para inyectar su registrador en todas las clases que lo necesiten: https://docs.asp.net/en/latest/fundamentals/logging.html
“Esta técnica no se limita a los controladores, sino que puede ser utilizada por cualquiera de sus servicios de aplicaciones que utilicen Dependency Injection”.
Por otro lado, aquí hay un artículo (patrocinado por Microsoft) que menciona un static enfoque de referencia: https://msdn.microsoft.com/en-us/magazine/mt694089.aspx?f=255&MSPPError=-2147217396
“Como puede notar, esto requiere acceso a la misma instancia de fábrica de registradores en la que se configuraron previamente los proveedores. Y si bien es posible que pueda pasar la instancia de fábrica de registradores a cada clase desde la que desee realizar el registro, rápidamente se convertiría en un molestia que suplicaría una refactorización.
La solución es salvar una static ILoggerFactory como static propiedad que está disponible para todas las clases al crear una instancia de ILoggger específica de su objeto. Por ejemplo, considere agregar un ApplicationLogging static clase que incluye un static Instancia de ILoggerFactory: “
Sin tratar de avivar los debates estático frente a DI frente a localizador de servicios: patrones o antipatrones, personalmente considero que las preocupaciones transversales comunes, como el registro y la configuración, son candidatos para este último enfoque, pero he usado ambos en el pasado.
Compartiendo las preocupaciones de Bjorn Reppens con respecto a la respuesta aceptada y teniendo en cuenta los comentarios de Cyprien Autexiers, terminé con esta solución (reducida) para “construido en DI” sin “constructores contaminantes” en “otras clases además del controlador” en .NET Core 3.1
Fábrica:
public class Runtime
public static ILogger GetLogger()
using var serviceScope = host.Services.CreateScope();
var services = serviceScope.ServiceProvider;
return services.GetRequiredService>();
static IHost host;
CancellationTokenSource CancellationSource get; = new CancellationTokenSource();
Task hostTask;
public void Start()
var hostBuilder = Host.CreateDefaultBuilder();
hostBuilder.ConfigureWebHostDefaults(webBuilder => webBuilder.UseStartup());
host = hostBuilder.Build();
hostTask = host.RunAsync(CancellationSource.Token);
Cliente:
public class OtherClass
ILogger Logger get;
public OtherClass() => Logger = Runtime.GetLogger();
Para mayor abstracción:
public abstract class LoggerBase
protected ILogger Logger get;
protected LoggerBase() => Logger = RunTime.GetLogger();
p.ej
public class OtherClass : LoggerBase
public OtherClass() => Logger.LogInformation("Instantiated");