Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
You’ve run into it. MediatR throwing an InvalidOperationException when you didn’t have a matching handler for a request. There’s a fairly simple solution to prevent this: Find MediatR Requests without Handlers.
So here’s some quick code you can throw in a unit test to verify you don’t have any missing handlers.
Find MediatR Requests without Handlers
The above code uses reflection to get all theIRequest<>, RequestHandler<> and RequestHandler<,>. Also worth mentioning it leverages Autofac for the IsClosedTypeOf method in the linq query.
I always nest my Handler class inside each Request class so I haven’t run into this problem, but this is a nice approach, thanks!
public class Ping : IRequest<Ping.Pong> {
public class Pong {
}
internal class Handler : IRequestHandler<Ping, Pong> {
public Pong Handle(Ping request) {
return new Pong();
}
}
}
Interesting. Never thought of doing that actually. Mainly this comes up when someone creates a handler for the wrong request. Simply by autocomplete and having the wrong type/request for the handler because the type names might be somewhat similar.
I do this as well; actually the other way around (the request is nestled inside the handler). But something about it feels… dirty. As in I haven’t really achieved any ‘separation of concerns’ between the request and the handler or something like that with this code style. But then again… whose concerns are they anyway? If I like the style of this approach then as long as I am pleasing myself and my team… who cares?
I also tend to have a handler class implement multiple IRequests (all nested within the handler). So the handler has multiple implementations of Handle() with different argument types. I’m getting more uneasy about this approach, bit of a violation of the S in SOLID but then again… as long as the code style is consistent who really cares?
Fortunately its all pretty easy to refactor away into separate classes at some point.
That’s an interesting approach with the Request inside the Handler, never thought of that.
We have each Request with nested Response and Handler in a single file because each Request represents an endpoint in our API so it is nice to have the entire atomic unit together with the documentation, et al. We then codegen Swagger, TypeScript, etc that are used by the front-end. While our Request and Response classes are public, the Handler is internal to our domain/business assembly since it has the “implementation” of the Request and has dependencies on the database or whatever services get injected which we don’t want to expose. In fact, all our Handlers for each Request are just called “Handler” 🙂
I gotta say the team really likes this approach, since to add a new endpoint they only have to touch a single file on the backend since all our Requests are executed by the frontend via JsonRPC. I lay it out here for a local user-group talk I gave with a basic open-source version of our JsonRPC, MediatR execution stuff (we call the pattern Commands, which encompasses the Request/Response/Handler:
https://github.com/Command-R/CommanderDemo