Closed KANekT closed 8 months ago
Per the README, the ICommand and IQuery interfaces were added for semantic "correctness", because the original MediatR by Jimmy Bogard only uses IRequest.
What do I mean by semantic correctness? Mediator libs are typically used in applications that apply a CQRS style or approach (command/query responsibility segregation) that, as the name implies, strives to separate the use-cases, models, services, and even at times the data storage, for operations/use-cases that query data only to display/return out to the caller vs. those operations which are commanding the app to create/update/delete some data.
The original MediatR lib calls both of those "requests", as it's trying to be agnostic of CQRS.
This lib provides synonymous interfaces to the "request", but which are more semantically close to CQRS commands and queries.
so, to directly answer your Q - IF you're building an HTTP API, then yes, you can relate the HTTP verbs to the query vs. command, so that GET requests are executing readonly Queries against your application. All other HTTP verbs that imply some data change (POST/PUT/DELETE, etc) are executing Commands against your application.
TL;DR; - they all do the same thing, but if you are doing CQRS, you could/should be more specific and use command and queries instead of requests for all things.
Indeed, great answer! And I've sometimes used that distinction to have some IPipelineBehavior
execute only for queries, with a generic contraint (caching behavior for example, which doesn't really make sense for commands)
where and for what to use a specific interface IRequest/ICommand/IQuery ?
maybe there is documentation or another article for understanding
May be: as rest
IQuery - get ICommand - post/put/deleted