I’ve recently been exploring MediatR Pipeline Behaviors and cross-cutting concerns (logging, validation, security, transactions) but also wanted to tackle some performance and resilience scenarios that may not always apply to every request/command (retry, fallback and caching).
Here are some gists that tackle these concerns:
Caching Behavior (using ASP.NET Core IDistributedCache):
For caching, I’m using a separately defined CachePolicy similar to a FluentValidation Validator class.
Fallback Behavior (using Polly):
For Fallback and Retry behavior, I’m using separate interfaces IFallbackHandler and IRetryableRequest to get the behavior.
Retry Behavior (using Polly):
These can all be combined as well and work based on the order they’re registered in Startup.cs. In my case, I want my main Handle method to retry, then, optionally, fallback to my HandleFallback, then finally cache the result based on the defined CachePolicy.
I’m debating between using separately defined classes/policies (like FluentValidation Validators) vs. making Handlers implement the interfaces to get the behavior. On one hand, if they’re separate, I could move the Cache, Fallback and Retry policies to separate files, folders, etc. and keep my main MediatR handlers very lean and clean. If you want to see them in the same place, you could put them in the same file like many of Jimmy Bogard’s examples with Validators, etc. But if the files get too big and you want to separate them out, you could do that. However, with Retry and Fallback, it’s kind of nice seeing that with the main request handler.
Of course, all this gets wired-up and registered in Startup.cs. I’m using Scrutor to aid in discovery my Caching, Fallback and Retry policies. See below.
What do you think? Which approach do you prefer? Let me know in the comments.