In C# (serilog) , How to handle this design refactoring where Generic Interfaces + Parent/Child relationships can be retained in a correct way?

Question

We have existing services where interface for Logging is injected into Child constructors and passed on to its parents (base).

Existing:

Public class Child: Parent
    public Ctor(ILogger logger) : base(ILogger logger)

New: (Modified ILogger to IMyLogger which internally uses Serilog Logger APIs for logging)

Public class Child: Parent
    public Ctor(IMyLogger<Child> logger) : base(IMyLogger<Parent> logger)

The above will obviously not work. But I need to work around this because these constructors are mostly used only Unittesting purposes or to retain a certain hierarchy chain which will be used while registering with DI framework!

Why I need to introduce a generic Logger is to bind a type to the Logger implementation which I can use later as my Serilog Source Context.

2 ways I can fix the above refactoring:

Options

1. Retain ILogger and not make in Generic. Use StackFrames to find the caller Type and assign it to SourceContext which will later be logged
2. Refactor ILogger to ILogger<T> but not pass the logger to base constructor.

Public class Child: Parent
    public Ctor(ILogger<Child> logger) : base()

Option 1 uses reflection and we can never rely on the Stack Frames to find the correct method which made the Logging call. Also performance will be impacted.

I feel option 2 is a cleaner way where each Child will have its own Context based Logger<Myself> which can later be mocked in Unit Tests.

Loggers should be one each for each service I feel. But am open to get pounded by varying thoughts and other better ways to handle this design. :-)

Answer 1

Fody Anotar

Why I need to introduce a generic Logger is to bind a type to the Logger implementation which I can use later as my Serilog Source Context.

I've had a lot of success using the Anotar.Serilog add-in for Fody, so I don't have to worry about details like this.

Your Code

public class MyClass
{
    void MyMethod()
    {
        LogTo.Debug("TheMessage");
    }
}

What gets compiled

public class MyClass
{
    static ILogger logger = Log.ForContext<MyClass>();

    void MyMethod()
    {
        if (logger.IsEnabled(LogEventLevel.Debug))
        {
            logger
                .ForContext("MethodName", "Void MyMethod()")
                .ForContext("LineNumber", 8)
                .Debug("TheMessage");
        }
    }
}

The one potential draw-back is that you can't easily test the logging behavior of your class in unit tests, because you're not invoking an injected, mockable interface. But I've tried a lot of different approaches over the years, and this one has far-and-away the most advantages and the fewest disadvantages. Besides, I've come to feel that logging is a cross-cutting concern that's kind of set apart from the normal rules of software architecture.

See https://github.com/Fody/Anotar

Avoiding generics with injection

But if you really like using an injected ILogger, you should be able to avoid injecting a generic type. Inject a non-generic ILogger instead. The details will depend on your DI framework, but they pretty much all will allow you to define injection using a factory that is aware of the type that you're injecting into. You can pass that type into the CreateLogger(ILoggerFactory, Type) extension method.

Of course, that means when your Base class emits a log message it will appear to be coming from its child class, which seems weird to me. You could use Property Injection instead of Constructor Injection for your loggers to avoid this.

Or you could avoid the problem entirely by re-architecting your classes to favor composition over inheritance. Usually you can just inject the Parent class into the Child class as a dependency, and end up with a better design pattern in the long run.