When implementing your business logic inside your handler, you may want to perform some actions as a side effect of your processing.

Having those in your handler might bloat your code or result in duplication if you want to perform some of them in several handler.

MediatR Notifications might come handy in such cases, let's see how !

Setup

First, let's create setup our example. We will create a simple web API using .NET 6:

~$dotnet new webapi-o MediatrNotification

In your favorite editor, remove any occurrences of the initial boilerplate (WeatherForecast.cs andControllers/WheatherForecastController.cs)

Finally, add MediatR and initialize it:

~$dotnet add package MediatR~$dotnet add package MediatR.Extensions.Microsoft.DependencyInjection

// Program.cs+ using MediatR;var builder = WebApplication.CreateBuilder(args);// Add services to the container.+ builder.Services.AddMediatR(typeof(Program));

Use case

For our demo, we will have a single endpoint, allowing someone to order a bouquet of flowers.

Based on that example, we can create our request in a new filePlaceBouquetOrderRequest.cs:

// PlaceBouquetOrderRequest.cspublicclassPlaceBouquetOrderRequest:IRequest<Guid>{publicDateTimeDueDate{get;init;}publicintFlowersCount{get;init;}publicstring?Note{get;init;}}

and initialize the handler alongside it:

// PlaceBouquetOrderRequest.cspublicclassPlaceBouquetOrderRequestHandler:IRequestHandler<PlaceBouquetOrderRequest,Guid>{publicTask<Guid>Handle(PlaceBouquetOrderRequestrequest,CancellationTokencancellationToken){varorderId=newGuid();// Send the order to the merchantreturnTask.FromResult(orderId);}}

Finally, create the associated controller inControllers/BouquetController.cs:

// BouquetController.cs[Route("api/[controller]")]publicclassBouquetController:ControllerBase{privatereadonlyIMediator_mediator;publicBouquetController(IMediatormediator)=>_mediator=mediator;[HttpPost("order")]publicasyncTask<IActionResult>PlaceBouquetOrder([FromBody]PlaceBouquetOrderRequestrequest){varorderId=await_mediator.Send(request);returnOk(orderId);}}

Adding the side effects

Our app is running great but now our client want us to also send an event to the merchant's calendar so that he can have an overview of its schedule.

Please note that we won't perform any validation here since that's not the goal of this tutorial

Let's go back toPlaceBouquetOrderRequest.cs and add the additional changes:

publicclassPlaceBouquetOrderRequestHandler:IRequestHandler<PlaceBouquetOrderRequest,Guid>{publicTask<Guid>Handle(PlaceBouquetOrderRequestrequest,CancellationTokencancellationToken){varorderId=newGuid();// Send the order to the merchantSendReminderToCalendarAt(request.DueDate);returnTask.FromResult(orderId);}privatevoidSendReminderToCalendarAt(DateTimedueDate){// Send a reminder to the merchant's calendar}}

The problem

Unfortunately, there are a couple issues that you might find from there:

• OurPlaceBouquetOrderRequestHandler, once in charge of placing bouquets orders, is now also in charge of scheduling reminders: its scope is growing outside its original responsibility
• TheSendReminder logic could be reused somewhere else and would require either to duplicate the method or to extract it into a dedicated service. However, creating a service might result in an object altering the structure of the code, designed around handlers.

A solution

If we take a moment to think about it, the action requested is more about "doing something when an order has been placed" rather that just sending a reminder.

Fortunately MediatR has such an object to represent those events and handling them, they are calledNotifications.

Let's create one to solve our case !

In a newBouquetOrderPlacedEvent.cs, create the following event:

// BouquetOrderPlacedEvent.cspublicclassBouquetOrderPlacedEvent:INotification{publicGuidOrderId{get;init;}publicDateTimeDueDate{get;init;}}

We can now create an event handler able to process those kind of notifications:

// BouquetOrderPlacedEvent.cspublicclassBouquetOrderPlacedEventHandler:INotificationHandler<BouquetOrderPlacedEvent>{publicTaskHandle(BouquetOrderPlacedEventnotification,CancellationTokencancellationToken){SendReminderToCalendarAt(notification.DueDate);returnTask.CompletedTask;}privatevoidSendReminderToCalendarAt(DateTimedueDate){// Send a reminder to the merchant's calendar}}

And replace our former logic in our handler by the emission of this event:

// PlaceBouquetOrderRequestHandler.cspublicclassPlaceBouquetOrderRequestHandler:IRequestHandler<PlaceBouquetOrderRequest,Guid>{privatereadonlyIPublisher_publisher;publicPlaceBouquetOrderRequestHandler(IPublisherpublisher)=>_publisher=publisher;publicTask<Guid>Handle(PlaceBouquetOrderRequestrequest,CancellationTokencancellationToken){varorderId=newGuid();// Send the order to the merchant_publisher.Publish(newBouquetOrderPlacedEvent{OrderId=orderId,DueDate=request.DueDate});returnTask.FromResult(orderId);}}

Going further

If we plan on handling new kinds of orders, we can generalize our event to anOrderPlacedEvent to abstract it from the kind of order it is:

// BouquetOrderPlacedEvent.cspublicabstractclassOrderPlacedEvent:INotification{publicGuidOrderId{get;init;}publicDateTimeDueDate{get;init;}}publicclassBouquetOrderPlacedEvent:OrderPlacedEvent{}

We can then make our handler generic so that it can handle any event derived from the base classOrderPlacedEvent:

publicclassOrderPlacedEventHandler<TOrderPlacedEvent>:INotificationHandler<TOrderPlacedEvent>whereTOrderPlacedEvent:OrderPlacedEvent{publicTaskHandle(TOrderPlacedEventnotification,CancellationTokencancellationToken){SendReminderToCalendarAt(notification.DueDate);returnTask.CompletedTask;}privatevoidSendReminderToCalendarAt(DateTimedueDate){// Send a reminder to the merchant's calendar}}

Note that if we had just changed our handler's definition topublic class OrderPlacedEventHandler : INotificationHandler<OrderPlacedEvent>, MediatR would not have correctly route the event to our handler. You can read more about it onthis issue.

Take aways

Andvoilà, we moved our logic into a dedicated handler, that might later also handle order of a different types. We also kept the logic of our handler as close as possible to its current use case and would also probably have reduced the handler's dependencies if we really implemented the communication with a third party calendar service.