Follow up question from yesterday's meetup
Now that I've had time to review what was discussed I think I can now ask the question I'd wanted to more accurately than I could at the time.
This question is specifically targeted at aspects that you might create that would target a wide variety of methods. An obvious example here is logging so we'll stick with that but logically the principle would apply yo any any all general purpose aspects.
We can create a straightforward and that aspect will be applied to different methods via the dynamic? OverrideMethod .
We could though create specicific implementations for different method types like async using alternative templates that use OverrideAsyncMethod() or OverrideEnumerableMethod() to name but two. With that said here come the questions. Would it actually be best practice in such situations to create templates for all the possibilities one is likely to encounter? One would obviously have to determine which template is applied and when, which presumably would be done via the override of BuildAspect. Am I correct in my thinking here?
We could though create specicific implementations for different method types like async using alternative templates that use OverrideAsyncMethod() or OverrideEnumerableMethod() to name but two. With that said here come the questions. Would it actually be best practice in such situations to create templates for all the possibilities one is likely to encounter? One would obviously have to determine which template is applied and when, which presumably would be done via the override of BuildAspect. Am I correct in my thinking here?
4 Replies
I think in general you should always consider whether what your advice does is possible using a "normal" method template and whether the result of using such universal template has satisfactory results.
Specifically for IEnumerable - currently we are running into a limitation, where the "normal" template will always cause the ".Buffer()" call to be generated when targeting IEnumerable (and similar). This happens even when the template does not do anything with the return value. I think this is something we can improve.
Thanks Daniel
Aside from the limitation with enumerables, I think it would be quite common to arrive at the exactly same template code, i.e. you would specify the same template, which would be equivalent to specifying only the default template.
I think it might be a best practice to always test the async and enumerable scenarios as long as you allow the usage.
That's my current line of thinking. I'll have to build some more tests into the app to cover those scenarios and see what comes out of them.