Closed tillig closed 2 years ago
Looks like I'll need to add a test for that exception condition.
Merging #12 (cf792a5) into develop (870c783) will increase coverage by
0.38%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## develop #12 +/- ##
===========================================
+ Coverage 97.87% 98.26% +0.38%
===========================================
Files 4 4
Lines 94 115 +21
Branches 17 18 +1
===========================================
+ Hits 92 113 +21
Misses 1 1
Partials 1 1
Impacted Files | Coverage Δ | |
---|---|---|
...ac.Extras.AggregateService/ResolvingInterceptor.cs | 97.36% <100.00%> (+1.00%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 870c783...cf792a5. Read the comment docs.
Added the test for #11 and, for the case of methods with generic parameters, switched the
ResolvingInterceptor
to dynamically create aFunc<X, Y>
delegate type based on the parameter types and return type for the method, then use that resolved factory for the method backing.The biggest challenge around generic parameters is that, while you might have
OpenGenericImpl<string>
as a parameter, someone could also dopublic class MyClosed : OpenGenericImpl<string>
and pass one of those as the parameter, so you get into type casting and compatibility challenges... which we've already solved in core Autofac. Hence the desire to reuse that logic and not mirror it here.I didn't add caching for the
Func<X, Y>
type signature; we'd need to add method caching and matching logic something similar to the constructor caching and matching in core Autofac which seemed a little overkill here. It does mean for every method invocation (for methods with generic parameters) it's two resolution calls - one to get the factory, one to get the resolved object. Not sure if that's acceptable, but it seemed the simplest way to add support to for open generic methods/parameters.I did leave the original logic for methods that don't have generic parameters so it's still reasonably optimal.
Generic return types don't appear to have any impact here, so there was no special requirement or change to handle that.