‘where should never send requests from anywhere inside a request handler.”

Why is that?

You have a chain of send requests, you then have a potentially multistage / distributed transaction but no way to roll back! First mediator handler works, but downstream handler doesn't, what do you do? Publishing reinforces the fact that something should have "happened already" and you are just publishing a message to reflect that fact.

I wouldn’t do tx sharing cross handlers.

I’m sometimes using it as way of composition / orchestration.
The simplified request/response/handler kinda forces single responsability, versus services clases that tend to become a mash of everything. Or at least to me it feels that it s guiding me towards the “pit of success”.

The only problem I see it is that it begins to look a lot like ServiceLocator, hiding dependencies. I guess you could inject the IHandler directly.

I guess you could inject the IHandler directly.

As illustrated in the first example of http://scotthannen.org/blog...

That blog was really interesting and made me question a lot until I looked at my current project and realised it had overlooked the pipeline behaviours. I have various projects using pipeline stages to handle retries, timeouts, and metrics that are easily configured and then reused across many the handlers for many different queries and commands. I think that's more than enough to meet Scott's "All code must justify itself" rule.

Meanwhile, maybe we could have ISender<tquery,tresponse> and ISender<tcommand> interfaces that only allow the sending of a single type of query or command. It wouldn't be particularly painful to teach the service provider how to generate ISender implementations from the IMediator. A given class would only need its exact ISender dependencies injected instead of taking the whole IMediator, which neatly avoids the service locator antipattern while still having a full-powered MediatR pipeline.

That's a good point about the pipelines. And a good idea regarding the generic ISender interfaces as well.

Hello. Is there a comprehensive article to explain why and how we should use `IPublisher`? And probably a real world sample code. Thx.

Thanks Jimmy!

Have you ever wondered about extending Mediatr to allow use of strategy pattern?
Woul be quite nice if request object could map string or type object and handler was chosen based on it (but with shared request to avoid if statements) ?

Another idea I had, my team finds ourselves in need for multiple validators, one for checking the request object properties and one for domain logic, would be nice to be able to split those with fluent-validator :)

Soo it mean that calling Mediator.Send(...) from command handler as nested command is not good practice? I do this for example I have UploadFile command that takes parameters and than i have concrete commands that call it (UploadUserAvatar/UploadProjectFile) they just have aditional check and fire this universal command on end... all wrap in try catch so i can do rollback or is this wrong practice?

Here's where I currently "Send" inside a requesthandler:
- querying additional data used to correctly handle the request from another context (in modular monolith)
- keeping notification handlers dumb COMMAND => HANDLER => AGGREGATE => EVENT => PUBLISH => EVENT HANDLER => COMMAND

Is the cake a lie?

I skip the command at the end, and have the event handler do the work directly

Is IMediator still available?

Yes