How do I log from other classes than the controlle

Question

ASP.NET Core has built-in support for logging, but the documentation states that logging should be done by requesting an ILogger via dependency injection, i.e. by adding it as an argument to the Controller constructor.

Polluting method signatures or constructors throughout my code with ILogger arguments feels like the wrong solution for this cross-cutting concern. In Android the Log class is static, making it trivial to log from any part of the code.

What would be a good way to do logging from other places than the controller?

Answer 1

Regarding using logging in any component:

Adding logging to a component in your application is done by requesting either an ILoggerFactory or an ILogger<T> via Dependency Injection. If an ILoggerFactory is requested, a logger must be created using its CreateLogger method.

If your CustomClass is a data container (DTO class), it should not know about logging, but just contain data.

For other classes with names like "Service" , "Provider", "Handler" and so on, the best practices is to resolve instances using dependency injection. In general, you should use DI wherever it is possible, as it’s a technique for achieving loose coupling between objects and their collaborators or dependencies. For more information, the following question might be interesting: Should I use Dependency Injection or static factories?

So simply add ILogger<CustomClass> to its constructor (actually the same way, as you do for controllers), as .NET Core supports only constructor injection by default:

public class CustomClass
{
    private readonly ILogger _logger;

    public CustomClass(ILogger<CustomClass> logger)
    {
        _logger = logger;
    }
}

---

ASP.NET Core’s built-in dependency injection container will automatically resolved transient dependencies. So if your controller has class A as a dependency that uses class B where you want to log something, your code can be something like this:

public class MyController
{
    public MyController(ClassA classA)
    { ... }
}

public class ClassA
{
    public ClassA(ClassB classB)
    { ... }
}

public class ClassB
{
    private readonly ILogger _logger;

    public ClassB(ILogger<ClassB> logger)
    {
        _logger = logger;
    }

    public void DoSomethingWithLogging()
    {
        // use _logger
    }
}

Note that you also need to register the dependencies in Startup using IServiceCollection.Add… methods:

public void ConfigureServices(IServiceCollection services)
{
    // ...

    services.AddTransient<ClassB>();
    services.AddTransient<ClassA>();
}

---

Built-in logging support means that .NET Core out of the box knows about and is using built-in abstractions for logging. This is mainly done by ILoggerFactory and ILoggerProvider interfaces.

/// <summary>
/// Represents a type used to configure the logging system and create instances of <see cref="ILogger"/> from
/// the registered <see cref="ILoggerProvider"/>s.
/// </summary>
public interface ILoggerFactory : IDisposable

// <summary>
/// Represents a type that can create instances of <see cref="ILogger"/>.
/// </summary>
public interface ILoggerProvider : IDisposable

Using your own ILoggerProvider implementation, you can add your own logger that can do whatever you want. You can check the NLog logger implementation as working example.

And thanks to ILoggerFactory, you can simply configure your Logger for project-specific purposes:

To configure logging in your ASP.NET Core application, you should resolve ILoggerFactory in the Configure method of your Startup class. ASP.NET Core will automatically provide an instance of ILoggerFactory using Dependency Injection when you add a parameter of this type to the Configure method.

Answer 2

This article indicates that you should use DI to inject your logger in all classes that need it: https://docs.asp.net/en/latest/fundamentals/logging.html

"This technique is not limited to controllers, but can be utilized by any of your application services that utilize Dependency Injection."

On the other hand, here is an article (Microsoft sponsored) that mentions a global static reference approach: https://msdn.microsoft.com/en-us/magazine/mt694089.aspx?f=255&MSPPError=-2147217396

"As you may notice, this requires access to the same logger factory instance on which the providers were previously configured. And while it’s conceivable you could pass the logger factory instance into every class from which you want to perform logging, it would quickly become a hassle that would beg for refactoring.

The solution is to save a single static ILoggerFactory as a static property that’s available for all classes when instantiating their object’s specific ILoggger instance. For example, consider adding an ApplicationLogging static class that includes a static ILoggerFactory instance:"

Not trying to stoke the Static vs. DI vs. Service Locator: Pattern or Anti-pattern debates, I personally find common cross-cutting concerns such as logging and configuration to be candidates for this latter approach, but have used both in the past.