C# Logging via DispatchProxy

Question

Considering many possible ways to handle cross-cutting concerns like Logging, I think a good way to handle them is via Interception. (Also Mark Seemann in his book "Dependency Injection in .NET" mentions Interception as a valid solution for cross-cutting dependencies.)

But in my specific case I would like to use .Net Core and it's DispatchProxy. And for Logging Microsoft's Logging Extension.

It is quite easy to intercept method calls with a generic proxy and to log the calls on Debug level. But how do I log with an interceptor information logs that might occur inside the method? I had the idea to implement in each class that needs logging an empty Log() method that accepts abstract log information as parameter. So if the user needs to log anything informational he can call this method and provide the log content. When this method is called the interceptor can intercept and based on the argument distinguish from other methods. Subsequently the information will be logged without the caller needing to depend on the logger interface.

My only concern is that I might violate a principle? Or is there anything else to consider?

public class Foo 
{    
    public void someMethod()
    {
        // do stuff
        this.Log(new MyLog("Log this information"));
        // do stuff
    }

    private void Log(ILog mylog) { }
}


public Interface ILog
{
    string Message;
    Exception Ex;
    LogLevel level;
    // anything worth logging
}

@Cromm The DispatchProxy will be used in the composition root. In my case im writing a class library, so it will be in the constructors of the initial class. Then I'm basically passing down the decorated objects. — Josh, Nov 20 '19 at 14:17

Steven · Accepted Answer · 2019-12-18T06:44:15.563

But how do I log with an interceptor information logs that might occur inside the method?

This is a scenario that is unsuited for Interception (both Dynamic Interception and Decoration). In that case the best approach is to inject a logging abstraction into your class using Constructor Injection:

public class Foo 
{
    private readonly ILog log;

    public Foo(ILog log) => this.log = log;

    public void someMethod()
    {
        // do stuff
        this.log.Log(new MyLog("Log this information"));
        // do stuff
    }
}

Although you could get this working using a virtual Log method that can be implemented using a Dynamic Proxy framework, this adds much more complexity compared to simply injecting that Volatile Dependency into the constructor. Also consider how you would go about testing those logging calls. You will have to create derived implementations of your components just for the purpose of testing.

But before injecting loggers into your consumers, do ask yourself: Do I log too much?

Also note that the second edition of Dependency Injection in .NET goes into more detail about good and bad logging strategies and also gives an alternative to Dynamic Interception (in chapter 10).

Although I would have loved to hear more answers on this topic, I understand your point and marked it as solution. I wasn't aware that there is a 2nd edition to the book. I'll buy it and am curious what Mark has to say in this edition on cross-cutting concerns. — Josh, Nov 21 '19 at 05:16
Actually I'm wondering now if one should log inside of methods. Methods should be small enough to be able to log anything from outside with interception (before, after and on exception). When I need to generate logs inside of a method I think the method is doing too much. — Josh, Nov 22 '19 at 06:21
My experience is that you will have to have method-specific logging statements from time to time, but they should be quite rare if you have an application design that is centered around the SOLID principles. — Steven, Nov 22 '19 at 06:33

C# Logging via DispatchProxy

1 Answers1