Logging MediatR Requests

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.

Leave this field empty if you're human:

With the MediatR v3, there is the ability to create your own request pipelines. To help out of the box, there are some predefined behaviors to help out with commen tasks such as pre and post request. These are RequestPreProcessorBehavior<,> and RequestPostProcessorBehavior<,> I’ve blogged about the new behaviors before but you can do it more generically.

Cross Cutting Behavior

I was looking at the pipeline to handle cross-cutting concerns like logging and metrics, which I would want on each command/query.

— Scott Banwart (@sbanwart) September 6, 2017

Logging

Pretty typical scenario of wanting to log incoming requests.   One common use case would be to store the incoming requests as a message store.

Registration

The next piece of the puzzle is making sure you register the RequestPreProcessorBehavior<,>with the DI container you are using with MediatR.  In the case of StructureMap that looks like:

Result

The end result is that any Request will run through the new RequestLogger.  You could log to a provider, serialize to your own data store, etc. Speaking of storing, I’m in the middle of implementing a message and command store in MySQL for Brighter, so stay tuned for a bunch of blog posts related it soon! What type of pipelines are you using with MediatR?  Do you have any type of command or message store?  Let me know in the comments or on Twitter.