Mediatr: Suggested Extensions

[FuncLun]

Would it be possible to add a few Extensions allowing the sentence structure to be inverted when using MediatR?

_Instead of doing this:_

mediator.Send(request);

mediator.Send(new Request()
{
    Message = "Message"
});

handler.Handle(new Request()
{
    Message = "Message"
});

_Do this:_

request.Send(mediator);

new Request()
{
     Message = "Message"
}.Send(mediator);

new Request()
{
     Message = "Message"
}.Send(handler); 

Extensions for Send and Publish:
https://gist.github.com/FuncLun/3876018345f6c6dc3b494ec0a2c6219a

Those extensions use Send/Publish to IRequestHandler/INotificationHandler, allowing you to pass either a mediator or a handler.

[no1melman]

This feels a little obscure and it is weird that you would attach the send action to a DTO class. I'm not saying you can't have those extensions in your own project - I just feel they would be out of place in the MediatR library

[FuncLun]

I've taken a few days considering your point of not attaching a Send action to a DTO class. I'm not a fan of the Active Record pattern, which is what these extensions seem to promote by attaching the action to the object.

But, these are extensions and aren't really attaching the behavior to the DTO. It's just syntax sugar, providing a similar a pipelining syntax used by LINQ, PowerShell and Unix. You start with the most important thing (the request), then send it to the next important thing (mediator). When you mail a letter to someone, you don't start with the Post Office and send a letter. You write a letter, then send it to the Post Office - the letter itself does not own the 'sending' behavior.

We have been using these extensions in our projects since MediatR 3.x. But, after organizing and reducing dependencies, we've ended up with a single repo/project/build pipeline/nuget package with just these 4 extensions. If these were accepted into MediatR, it would not just reduce my dependency count (which has no importance to the community), but I hope the community could benefit to using the pipelining pattern. Hopefully, this pattern will appear less obscure after realizing where it's found elsewhere.

Consider the following code snippets. Mentally, you start with the first line, then second, then third, etc. With the second example, you start with the middle (myObject), look at the line above (Select), then the line below (o.MyString), then the line above (Where), then below (s != null), etc.

Consider the token. The token is more closely related to the Send action on Mediator, and less related to the request itself. The pipeline example has Send, mediator and the token right next to each other. In the other example, they are far apart. Imagine setting more Request properties, further separating mediator.Send and token.
``C# //C# Pipeline example //This also relies on an ExtensionTask WhenAll(this IEnumerable)`
await myObject
.Select(o => o.MyString)
.Where(s => s != null)
.Select(s => new Request() { Message = s }.Send(mediator, token))
.WhenAll();

//C# Non-Pipeline example
await Task.WhenAll(
Enumerable.ToArray(
Enumerable.Select(
Enumerable.Where(
Enumerable.Select(
myObject,
o => o.MyString
),
s=> s != null
),
s => mediator.Send(new Request() { Message = s }, token)
),
)
);

Trivial PowerShell pipeline example
```PowerShell
#PowerShell Pipeline example
#Start with the first task, finish with the last task
Import-Csv "input.csv" -ErrorAction Stop |
    Export-Csv "output.tsv" -Delimiter "`t" -ErrorAction Stop

#PowerShell Non-Pipeline example
#Start with the last task, middle has the first task, finish closing the last task
Export-Csv "output.tsv" -Delimiter "`t" -ErrorAction Stop -InputObject ( `
    Import-Csv "input.csv" -ErrorAction Stop `
)

As always, thank you for your time and consideration.

[valdirviana]

I guess that send action can't associated the a DTO class because this hurt the responsabilitie of the classes context

[FuncLun]

Created Pull Request for review

326

PipelineExtensions.cs allows a pipeline style of programming rather than nested style. (This is not related to PipelineBehaviors.) This style is possible with F#'s Pipe Forward operator. And, there is discussion in adding Pipe Forward operators to C# in csharplang.

[jbogard]

Closing until C# gets a pipe forward operator