• @canpolatOPM
    link
    English
    17 months ago

    Looks cool, but I think there may be two problems with this approach:

    1. Having traces for all methods with all parameters would be a problem for sensitive data.
    2. He doesn’t mention performance impacts, but I suspect this would impact performance.
    • @RonSijm
      link
      English
      27 months ago
      1. He doesn’t mention performance impacts, but I suspect this would impact performance.

      It looks like he’s using an Analyzer to generate interceptors. More detailed on how those interceptors works is pretty good explained here: https://www.youtube.com/watch?v=91xir2oUQPg

      So performance wise, this shouldn’t change the performance impact any more than manually wiring in loggers on every level. - It might slow down the compile time by a little bit though.

      A project that does something very similar but for Mediators is Mediator.SourceGenerator - an alternative to MediatR - but that project does it for Mediators instead of logging

      The “original” way of doing something like this was by using Castle DynamicProxy, and creating an interceptor at runtime. Which would affect runtime performance more than doing it compile time

      And another alternative way of doing the same thing would be using Fody - Creating logging attributes or interfaces, and then using Fody to wire in logging. Though Fody would be doing it during post-compile though an IL Weaver.

      So this Roslyn Source Generator weaving approach is basically the best way to approach this