Revise the request handler API

The current API is confusing.

• For some request handlers you implement an interface, for other request handlers you inherit from an abstract base class.
• The AsyncRequestHandler (with the word “async”) is used for asynchronous handlers, but IRequestHandler (without the word “async”) is also used for asynchronous handlers.
• There is a unconventional Unit struct to represent void.

Current API

The current API uses a mix of both interfaces and abstract base classes.

Description	Type	Name
Asyncronous with response	Interface	IRequestHandler<TRequest, TResponse>
Asyncronous without response	Abstract	AsyncRequestHandler<TRequest>
Syncronous	Abstract	RequestHandler<TRequest, TResponse>

Uhm, this is confusing and I am probably wrong here about something.

Proposal

Description	Type	Name
Asyncronous with response	Interface	IAsyncRequestHandler<TRequest, TResponse>
Asyncronous without response	Interface	IAsyncRequestHandler<TRequest>
Syncronous with response	Interface	IRequestHandler<TRequest, TResponse>
Syncronous without response	Interface	IRequestHandler<TRequest>

• Unify usage by always and consistently using interfaces for both sync and async, as well as for both with and without response.
• Drop the abstract base classes.
• Drop the Unit struct.

[lilasquared]

The move to a single interface (async first) was an explicit move for MediatR v4.0 - you can check out the release notes here https://github.com/jbogard/MediatR/releases/tag/v4.0.1

I agree with @khellang that the classes are simply convenience classes and are not part of public API / Interface of the library, they are simply implementations of the interface to reduce boilerplate code on the users part. Use them, or don’t. The public api for MediatR Handlers is simply

Description	type	Name
Asyncronous with response	Interface	IRequestHandler<TRequest, TResponse>
Asyncronous without response	Interface	IRequestHandler<TRequest>
Asyncronous without response	Interface	INotificationHandler<TNotification>

[vanillajonathan]

Yes and no. As I said in my first comment; they’re convenience classes to save you from writing some cruft, like wrapping results in a Task if your handler is synchronous, or returning Unit if you don’t care about the result. That’s it.

Well wrapping the result in a Task is rather simple, and I would say its easier than to figure out which of all those base classes to use. As for when not caring about the result, isn’t there the IRequestHandler<TRequest> interface for that?

I feel these base classes cause more confusion than convenience.