-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Mediator 3.0 design to support multiple configuration and fast switching. #128
Comments
Hi, sorry took a while to get to this. Thanks for looking into it! I have some questions and comments The idea here is supporting multiple calls to
What do you mean here, multiple handlers per request? I'm probably missing something since I'm stuck on how to even get the Regarding the code samples here with switches, I'd come to the conclusion that there is no fast (enough) switch. What makes these branches OK where the current ones aren't in terms of perf? As in The idea with .NET 8 interceptors was to eliminate the branches altogether. I think if that design were to collide with the scenario of having multiple impls/projects somehow then I would prefer to drop that to simplify. That said I don't have a clear picture of the project topology we're targeting in general or with this design, maybe you can write out some example solution that this design would go well with? |
I believe it's possible to merge the two design together in a way which would be fast, configurable and while supporting .NET Standard. See #98
Configuration
Add a property to
AddMediator
that accepts an array of types. At compile time the array is examined and all relevant Mediator types are added from their respective projects. This is used to create a unqiue implementation ofIMediator
used for thisAddMediator
call. We can use interceptors or psuedo-interceptors (using caller attributes) to return the respectiveMediator
class. This way we can have multiple configurable instaces ofIMediator
in one project.See #125
Using a pseudo-intercetor (interceptor could be used instead)
There are a variety of different configuration approaches, I chose this one for its simplicity to demonstrate the concept.
Fast type switching
Iirc one of plans for Mediator 3.0 attempted to resolve #7, by analyzing all calls to
ValueTask<TResponse> Send<TResponse>
and intercepting it with the correct method. Unfortunately this wouldn't be compatible with multiple projects per class as different type could be registered making it impossible to be sure that the relevant method exists on theIMediator
implementation and then calling it.Instead we could use a pseudo-interceptor to generate switch statements based upon known concrete type calls for each Mediator implementation. As each Mediator implementation has different types registered it would be neccessary to emit an exception when an invalid
IRequest
object is passed intoSend
.See #97
It's possible to achieve similar results using an interceptor by checking the type of
IMediator
to see if it supports the conreteIRequest
object.The text was updated successfully, but these errors were encountered: