Mediatr: Question/Discussion

[ArturKarbone]

Hi

I'm bootstraping a project and considering using the clean architecture as Uncle Bob calls it or one-model-in-one-model-out approach as @jbogard calls it in his great article.

In other words, I want to focus on the application logic and it's use cases first and completely separate them from a delivery mechanism (like MVC, API, etc.)

Just trying to figure out how can I leverage the marker interfaces and Mediatr library in general.

What this piece of code can really tell me about?

public class Query : IRequest<Result>

That the Query class is an inpunt for some mediator that returns some Result class ?

What does this mean:

public class Command: IRequest

That I don't need an explicit result, I just want to delete some record and triggering mediator's logic which does not assume returning a value (void for instance)?

Or marking my mediator/use case with the IRequestHandler is the way to enforce conventions?

public class QueryHandler : IRequestHandler<Query, Result>

meaning that all the implementation will have predictable structure at least:

public Result Handle(Query message)

and not Process, Execute, HandleThis, HandleThat, etc. (whatever name a developer is going to figure out).

To me having this interfaces is like leveraging conventions and having consistent structure among different mediators/use cases.

What do You think, guys?

[no1melman]

Personally I never bother with the approach of Command/Query. I just call them all Requests (Where requests may or may not return you a value).

The may or may not comes with the return type of IRequest<T> where if T is a Unit.Value I know this is acting like a "Command".

Then I just use naming conventions and follow SRP very closely, such as GetUserByIdRequest : IAsyncRequest<UserDto>, SRP because this is very specific, I want to get a user by id. I can then use the _Feature_ folder convention to group similar features together, like user manipulation, user access control etc.

Does this help?

[jbogard]

Yep, me too, sometimes I call them queries and commands, sometimes not, but
that's mainly a convention thing that queries are for GET requests and
commands are for POST requests. Ultimately, they're both requests.

On Mon, Jul 18, 2016 at 4:34 AM, Callum Linington [email protected]
wrote:

Personally I never bother with the approach of Command/Query. I just call
them all Requests (Where requests may or may not return you a value).

The may or may not comes with the return type of IRequest where if T
is a Unit.Value I know this is acting like a "Command".

Then I just use naming conventions and follow SRP very closely, such as GetUserByIdRequest
: IAsyncRequest

Does this help?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jbogard/MediatR/issues/90#issuecomment-233284641, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGYMtZSbODqrSGGk92-7gNPOAjNoIofks5qW0iXgaJpZM4JNbmH
.

[ShaneCourtrille]

If you do want to make things more explicit for your own team, nothing stops you from adding your own marker interfaces.

public interface IQuery<TResult> : IRequest<TResult>

public interface ICommand : IRequest<CommandResult>

I find it's useful to have a common command result that has conventions around its usage for 90% of your scenarios.