Artificial intelligence continues to reshape our industry—often for the better. It increases productivity, accelerates innovation, and reduces repetitive work. However, this transformation is not without its drawbacks. One emerging concern is the quiet erosion of human expertise, particularly when AI is used as a substitute for skill rather than a tool to enhance it.
Observability—the ability to understand what is happening inside your software systems—has become essential in today’s complex applications. While logs and traces provide valuable technical information, custom metrics unlock deeper insights by focusing on what truly matters to your business.
Move the elegance of ASP.NET Core middleware into any complex back-end workflow – without
HttpContext, without OOP builders, and without losing DI, cancellation or early-exit behaviour.
Business workflows such as Get GPS Logs often involve many steps:
Each step should be independent, replaceable, testable and able to short-circuit on error or empty data – the classic “Russian-doll” pattern that ASP.NET Core middleware delivers for web traffic.
DbContext Connection at RuntimeIn Entity Framework Core (including EF Core 9.x), the database connection is normally configured when the DbContext is
constructed, and it isn’t intended to be changed afterward. Once a DbContext is injected (e.g. via DI in a minimal
API), its DbContextOptions (including the connection string) are essentially fixed. There is no built-in method to
reconfigure the context’s connection string after it’s been created in the DI container. In other words, you cannot
directly “swap out” the connection string of an existing context instance once it’s been configured.
MediatR is a popular .NET library that implements the Mediator pattern for in-process messaging. It allows decoupling of request senders from their handlers by routing messages (requests/commands/queries) through a central mediator. Over the years it has become a staple in many “Clean Architecture” templates and CQRS-style projects, with over 286 million NuGet downloads as of 2025 (MediatR and MassTransit Going Commercial: What This Means For You). MediatR provides a simple request/response API and supports publish/subscribe for in-memory notifications, along with a pipeline behavior feature that enables plugging in cross-cutting concerns (like logging, validation, etc.) around those requests.
However, the landscape has changed in recent .NET versions (8 and beyond). The .NET platform now offers native features (such as minimal API endpoint filters, improved middleware, and powerful DI patterns) that cover many use cases MediatR was traditionally used for. Additionally, MediatR’s licensing has evolved – it is transitioning from a free OSS tool to a commercial (paid) product, raising questions about relying on it for core infrastructure (AutoMapper and MediatR Going Commercial) (MediatR and MassTransit Going Commercial: What This Means For You). This article provides a comprehensive evaluation of using MediatR in modern .NET applications, comparing its benefits and drawbacks to native alternatives, and offering guidance on when (if ever) it remains the right choice.