Find MediatR Requests without Handlers

Find MediatR Requests with no HandlersYou’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 the IRequest<>, RequestHandler<> and RequestHandler<,>.  Also worth mentioning it leverages Autofac for the IsClosedTypeOf method in the linq query.

Usage

Here’s a quick unit test that shows it’s usage for finding Requests without any handlers.  In the sample below I have two Requests without Handlers: MyRequestWithoutHandler and MyRequestWithResultWithoutHandler

Source

All the source code for my example is available on GitHub if you want to try it yourself.

Another useful test would be to verify that your container actually has the the request and behavior handlers registered correctly.  Another post to come with that.

Always love hearing your comments.  Please post them here or on Twitter.

 

4 thoughts to “Find MediatR Requests without Handlers”

  1. 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();
    }
    }
    }

    1. 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.

    2. 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.

      1. 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

Leave a Reply

Your email address will not be published. Required fields are marked *