search

jbogard / MediatR

Simple, unambitious mediator implementation in .NET
Apache License 2.0
11.06k stars 1.17k forks source link

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

Closed bryanboettcher closed 6 months ago

bryanboettcher commented 9 months ago

(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 commented 9 months ago

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

jbogard commented 8 months ago

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 commented 8 months ago

@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[bot] commented 6 months ago

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[bot] commented 6 months ago

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