this post was submitted on 27 Feb 2024
2 points (100.0% liked)
Talks
79 readers
2 users here now
A community to share and discuss good (conference) talks in/about software industry.
Please try to listen to a significant chunk of the talks before engaging in discussion and try to avoid responding just to the title of the talk.
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards other users for any reason
- No spam of tools/companies/advertisements.
Credits
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
founded 9 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Looks cool, but I think there may be two problems with this approach:
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