Category: Software Development

Tags:.NET, .NET DI, MediatR, Decorator Pattern, Dependency Injection, Clean Architecture, C#, Software Design Patterns, Microservices, Enterprise Applications,

Why Move Beyond MediatR? Understanding the Limitations of the Mediator Pattern

MediatR has long been a go-to library for implementing the Mediator pattern in .NET applications, especially in Domain-Driven Design (DDD) and Clean Architecture contexts. It simplifies communication between disparate components by decoupling senders from receivers, promoting loose coupling and enhancing maintainability. However, despite its advantages, MediatR introduces several pain points that can hinder long-term project health. First, it adds an external dependency, which may not align with projects aiming for minimal third-party libraries. Second, MediatR relies on reflection and runtime type resolution, which can lead to performance overhead and reduced debuggability. Third, the library abstracts too much, sometimes making it unclear how messages are dispatched or how behaviors are applied, especially for developers new to the codebase.

#dotnet #CSharp #SoftwareArchitecture #BackendDevelopment #CleanArchitecture #Softved

The Power of Native .NET DI Decorators

Native .NET Dependency Injection (DI) decorators offer a compelling alternative to MediatR by leveraging the built-in DI container introduced in .NET Core. Decorators allow you to wrap service implementations with additional behavior at runtime while preserving compile-time type safety. This approach eliminates the need for third-party libraries, reduces runtime overhead, and improves transparency in how cross-cutting concerns like logging, validation, and telemetry are applied. Decorators are registered in the DI container and can be chained, enabling modular and maintainable extensions without modifying core service logic.

• Compile-time type safety: No reflection, no surprises during execution
• Better debuggability: Clear stack traces and call chains
• Performance: Reduced overhead from dynamic dispatch
• No external dependencies: Uses built-in .NET features
• Flexibility: Easy to customize or extend behavior per service

Step-by-Step: Implementing Decorators for Cross-Cutting Concerns

Implementing decorators for logging, validation, and telemetry is straightforward with .NET’s DI container. Start by defining your base service interface and implementation. Then, create decorator classes that implement the same interface and accept the original service in their constructor. These decorators can log method calls, validate inputs, or track performance before delegating to the wrapped service. Register the decorators in the DI container using the `TryAddEnumerable` or `AddTransient`/`AddScoped`/`AddSingleton` methods, ensuring proper ordering if multiple decorators are applied.

• Define the service interface (e.g., `IOrderService`)
• Implement the concrete service (e.g., `OrderService`)
• Create a decorator class implementing `IOrderService`
• Inject the original service into the decorator
• Apply decorator logic (e.g., logging before calling `baseService.PlaceOrder`)
• Register the decorator in `Program.cs` or `Startup.cs`

Logging Decorator: Enhancing Observability Without Code Bloat

Logging is a prime candidate for decorator implementation. Instead of scattering `ILogger` injections throughout your service methods, wrap your service with a logging decorator that automatically logs method entry, parameters, and execution time. This keeps your business logic clean and centralized while ensuring every method call is observable. The decorator can use structured logging to integrate seamlessly with tools like Application Insights, Serilog, or OpenTelemetry. Example: A `LoggingOrderServiceDecorator` logs every order placement attempt, including user ID and order details, without modifying the original `OrderService`.

• Automatically log method entry/exit with parameters
• Support structured logging for integration with observability tools
• Centralize logging logic, avoiding duplication
• Preserve original service behavior
• Enable fine-grained control over log levels

Validation Decorator: Enforcing Business Rules at the Edge

Validation logic often clutters service methods, making them harder to read and maintain. A validation decorator can intercept method calls, validate inputs against business rules, and throw exceptions early if rules are violated. This approach aligns with the principle of failing fast and keeps validation logic separate from business logic. For instance, a `ValidationOrderServiceDecorator` can validate order details like quantity, customer age, and product availability before passing the request to the core `OrderService`. This decorator can reuse existing validation rules defined in FluentValidation or custom validators.

• Validate inputs before processing in core service
• Reuse existing validation rules (e.g., FluentValidation)
• Fail fast and provide meaningful error messages
• Keep business logic clean and focused
• Support complex validation scenarios with chained decorators

Telemetry Decorator: Monitoring Performance and Usage

Performance monitoring and telemetry are critical in production environments. A telemetry decorator can wrap service methods to track execution time, success/failure rates, and resource usage. This decorator can integrate with Application Insights, Prometheus, or custom metrics systems. For example, a `TelemetryOrderServiceDecorator` can record the duration of `PlaceOrder` calls and log slow transactions, helping identify performance bottlenecks without polluting the core service code. Decorators can also emit custom events for dashboards or alerting systems.

• Track method execution time and success rates
• Integrate with Application Insights, Prometheus, or OpenTelemetry
• Log slow transactions for performance analysis
• Emit custom metrics for dashboards
• Support distributed tracing in microservices

Chaining Decorators: Building a Pipeline of Behaviors

One of the most powerful features of decorators is their ability to chain together, creating a pipeline of behaviors. For example, you can combine a logging decorator, a validation decorator, and a telemetry decorator to process a single method call in sequence. The order of registration in the DI container determines the order of execution. This modular approach allows you to add or remove behaviors dynamically without changing the core service. It also makes it easy to test individual decorators in isolation.

• Register decorators in the desired order in DI container
• Each decorator wraps the next in the chain
• Behaviors execute in the order they are registered
• Easily add or remove decorators without modifying services
• Simplify testing by isolating decorator logic

Debugging and Testing Decorators in a Real-World Scenario

Debugging decorator chains can be challenging due to the indirection they introduce. However, .NET’s DI container and modern IDEs provide tools to mitigate this. Use the `IServiceProvider` to inspect registered services and their order. Breakpoints in decorators allow you to step through the call chain and verify behavior. For testing, write unit tests for each decorator in isolation and integration tests for the full chain. Mock the underlying service to verify decorator logic without executing business code. Example: A test for the validation decorator can mock `IOrderService` and assert that invalid orders throw exceptions.

• Use `IServiceProvider` to inspect registered decorators
• Set breakpoints in decorators to trace execution flow
• Write unit tests for individual decorators
• Use integration tests to validate decorator chains
• Mock underlying services for isolated testing

Performance Comparison: Decorators vs. MediatR

Performance is a critical factor when choosing between decorators and MediatR. Decorators leverage compile-time type resolution and direct method calls, resulting in minimal overhead. MediatR, on the other hand, uses reflection and dynamic dispatch, which can introduce measurable latency, especially in high-throughput scenarios. Benchmarks show that decorator-based pipelines can be 2-5x faster than MediatR for simple method calls. Additionally, decorators avoid the overhead of boxing/unboxing value types and reduce GC pressure, making them a better choice for performance-critical applications.

• Decorators use direct method calls (no reflection)
• MediatR relies on runtime type resolution
• Decorators reduce GC pressure and boxing overhead
• Benchmark results show 2-5x faster execution for decorators
• Ideal for high-throughput and latency-sensitive applications

Migrating from MediatR to Native DI Decorators: A Practical Guide

Migrating from MediatR to native DI decorators requires careful planning to avoid disruptions. Start by identifying all MediatR handlers and their behaviors (e.g., logging, validation). Replace each handler with a decorator and update the DI registration. Use feature flags to gradually roll out the new approach, allowing you to compare behavior and performance between the old and new systems. Gradually decommission MediatR once the new system is validated. Tools like `Microsoft.Extensions.DependencyInjection` and `Microsoft.Extensions.Hosting` simplify this transition by providing familiar APIs.

• Identify MediatR handlers and their behaviors
• Replace handlers with decorators implementing the same interface
• Update DI container registrations
• Use feature flags for gradual rollout
• Compare behavior and performance between old and new systems
• Decommission MediatR after validation

When to Choose Decorators Over MediatR (and Vice Versa)

Decorators and MediatR serve similar purposes but excel in different scenarios. Choose decorators when you prioritize performance, type safety, and minimal dependencies. Decorators are ideal for cross-cutting concerns like logging, validation, and telemetry in monolithic or microservices architectures. MediatR, however, shines in scenarios requiring complex message routing, request/response patterns, or integration with libraries like AutoMapper or FluentValidation. MediatR’s abstraction can simplify code in large applications where the mediator pattern reduces boilerplate. Ultimately, the choice depends on your project’s requirements, team expertise, and long-term maintainability goals.

• Choose decorators for performance, type safety, and minimal dependencies
• Use MediatR for complex message routing and request/response patterns
• Decorators excel in monolithic and microservices architectures
• MediatR simplifies code in large applications with many handlers
• Consider project requirements and team familiarity

Future-Proofing Your Architecture with Decorators

Native .NET DI decorators future-proof your architecture by reducing reliance on third-party libraries and leveraging built-in .NET features. This approach aligns with Microsoft’s vision for .NET, where the DI container plays a central role in application composition. Decorators also make it easier to adopt new .NET features like source generators, minimal APIs, and AOT compilation, as they rely on compile-time type resolution. By embracing decorators, you create a more maintainable, testable, and performant codebase that can evolve with the .NET ecosystem.

• Reduce reliance on third-party libraries
• Leverage built-in .NET features for long-term support
• Align with Microsoft’s vision for .NET DI
• Easier adoption of new .NET features (e.g., source generators)
• Create a more maintainable and testable codebase