Allow for an optional "Order" parameter to be set on implementations of pre, post, and exception handlers.

[bryanboettcher]

(this issue exists so I have a branch name to create my PR against)

There are many examples of users of MediatR wanting to execute pre & post-request handlers in order. For instance, running a validator to fail early before doing some heavier lookups or pre-populating with downstream processors. Many DI containers support adding these handlers in a specific order, but this means you cannot use a type scanner to auto-populate the list.

Newer versions of C# allow for auto-implementation of interface members. As far as I can tell, this is an ideal way to implement the idea of a numeric "Order". By adding an integer "Order" field, defaulting it to 0 in the interface, and ordering by "Order" when executing Pre/Post/Exception handlers, a developer could optionally support this feature in a native way with very little overhead.

[bryanboettcher]

Ok, I got outsmarted by multi-targeting support, so this implementation is going to have conditional compilation flags.

[jbogard]

The way I want to support this is directly in the list of pre/post request handlers. There's already an order in the Index property on the list. I don't want to add yet another way of specifying an order when the order is already intrinsically present in the list.

This is a bit different than filters in ASP.NET Core where you have attributes sprinkled all over your codebase with no central registration. I have central registration so that's where you should specify the order.

[bryanboettcher]

@jbogard Apologies for missing the bus with this then. Do you have a link / search term for MediatR's preferred method of registration? This issue came about because of typescanning and auto-registration, but based on whatever your answer is maybe I have a workaround for my issue.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 14 days with no activity.