Requests are really the center of all the action in the Mediator. Request can only be fulfilled/responded to by a single handler. Requests also have
the ability to respond with a result as well.
When issuing a request, we start a fresh Service Provider scope. This means that any dependencies that are registered as Scoped will be disposed of after the request is completed. If you need to maintain a dependency, you should register it as Singleton
Creating Requests
A request can be a class, record, or struct. It must implement the IRequest interface. If you want to return a result, then you must implement IRequest<TResult>
The request handlers are also very similar
Now, let’s register these guys through your host builder/DI container. They can technically work off any lifecycle you choose.
Finally, let’s send a request through the mediator
If you use IMediator.Request and TResult implements IEvent, mediator will publish that event for you before returning to the request caller
Middleware
In our opinion, this is where Shiny Mediator really begins to shine. Layering overtop of your requests with middleware is beautiful. We offer some excellent out of the box middleware. Be sure to check out it here
Middleware allows you to mutate the requests, response, or even short circuit the request. It’s a great place to do things like logging, error handling, caching, etc.
Let’s take a look at an sample piece of request middleware that handles a specific use-case
Now, let’s register this middleware with your host builder
Let’s take a look a general purpose middleware that handles any request
Make sure to register this middleware with your host builder using an open generic