Creating a reusable validation pipeline with MediatR

Creating a reusable validation pipeline with FluentValidation and MediatR gives .NET teams one consistent gate between an incoming request and business logic. Instead of scattering checks across controllers, endpoints, command handlers and consumers, developers express rules as validators and let a mediator pipeline run them before the handler. That arrangement suits the C# Corner Annual Conference 2020 audience, where sessions on C#, cloud, web and messaging often address connected concerns.

The goal is not to turn every business rule into a field check. Required fields, string lengths, ranges and formats suit validation well; cross-entity rules such as uniqueness usually belong to the domain or database. A robust pipeline also needs a stable failure contract, support for asynchronous rules, cancellation, and registration that works for an ASP.NET Core API, worker or message consumer.

Australian teams gain from a shared contract when people work across Sydney, Melbourne, Brisbane and Perth. Perth usually sits three hours behind the eastern states, subject to daylight saving, so an arvo handover can expose inconsistent local checks. Customer-facing messages should use Australian spelling such as “authorisation” and “organisation”, while C# names such as ValidationBehavior follow established framework conventions. Privacy Act 1988 and the Australian Privacy Principles also make careful error payloads and logging essential.

Put validation before business logic

MediatR keeps a command or query separate from the class that handles it. A request such as CreateCustomerRequest carries the input, while CreateCustomerHandler performs the use case. A generic validation behavior sits between them, locates every IValidator<TRequest>, evaluates those validators and stops the chain when errors exist. The handler therefore receives a request that has already met its input contract.

Using the MediatR API available for the 2020 event, the core of the behavior is small and transport-independent:

public sealed class ValidationBehavior<TRequest, TResponse> :
    IPipelineBehavior<TRequest, TResponse>
    where TRequest : notnull
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
        => _validators = validators;

    public async Task<TResponse> Handle(
        TRequest request,
        CancellationToken cancellationToken,
        RequestHandlerDelegate<TResponse> next)
    {
        var context = new ValidationContext<TRequest>(request);
        var results = await Task.WhenAll(
            _validators.Select(v =>
                v.ValidateAsync(context, cancellationToken)));

        var failures = results
            .SelectMany(r => r.Errors)
            .ToList();

        if (failures.Count > 0)
            throw new ValidationException(failures);

        return await next();
    }
}

Throwing a FluentValidation exception is useful inside the application layer because it avoids coupling reusable code to HTTP. A boundary component can translate it into an ASP.NET Core ValidationProblemDetails response, or a messaging adapter can record it as a rejected message. MediatR executes behaviors in registration order, so register validation ahead of behaviors that open transactions, publish events or make costly remote calls. That ordering ensures invalid input cannot trigger those side effects.

Design validators that work beyond HTTP

A validator should describe the shape and entry constraints of one request. This keeps it understandable to developers and useful to automated tests:

public sealed class CreateCustomerValidator
    : AbstractValidator<CreateCustomerRequest>
{
    public CreateCustomerValidator()
    {
        RuleFor(x => x.Name)
            .NotEmpty()
            .MaximumLength(120);

        RuleFor(x => x.Email)
            .NotEmpty()
            .EmailAddress()
            .MaximumLength(254);

        RuleFor(x => x.Postcode)
            .Matches("^[0-9]{4}$")
            .WithMessage("Postcode must contain four digits.");
    }
}

Validators compose well. A CustomerAddressValidator can be invoked from a customer validator, while custom rules can format currency, parse reference values or call an external service. Because FluentValidation does not depend on MVC, the same IValidator<TRequest> can run inside a MediatR behavior regardless of whether the request arrived through an endpoint or a queue. This is particularly valuable when a service moves a workload between a public API, an Azure-hosted worker and a scheduled integration without rewriting its rules.

Keep service-backed checks deliberate. A postcode lookup or customer-reference query may need IValidator<TRequest> with MustAsync, but every call adds latency, a network dependency and possible rate limits. Use cached reference data where suitable, pass the cancellation token and avoid querying for rules that the database must enforce anyway. Uniqueness is a good example: checking whether an email already exists before insertion creates a race, so the handler and a unique database index must provide the final guarantee. State codes such as ACT, NSW, NT, QLD, SA, TAS, VIC and WA can be validated locally, while authoritative postcode relationships belong in maintained reference data or a domain service.

Register the pipeline once

Dependency injection keeps registration visible and prevents each transport from assembling its own validation chain. A typical setup scans the application assembly for validators and MediatR handlers, then registers the open generic behavior:

services.AddValidatorsFromAssemblyContaining<CreateCustomerValidator>();
services.AddMediatR(typeof(CreateCustomerRequest).Assembly);
services.AddTransient(
    typeof(IPipelineBehavior<,>),
    typeof(ValidationBehavior<,>));

Depending on the MediatR package version, teams may use AddMediatR with a configuration delegate instead of the assembly argument. The important point is the shape: validators are discovered through IValidator<T>, and one behavior applies to all requests that need validation. A request without a validator can still pass because the dependency resolves to an empty collection; add a startup guard or marker interface if every command must have explicit input rules.

Place validation before transaction, retry and caching behaviors whose ordering matters. A common sequence is authentication context, validation, transaction, then the handler, although the correct order depends on the application. ASP.NET Core can add request validation through MVC or minimal APIs, yet the mediator behavior remains necessary for commands dispatched internally or consumed from a message broker. This avoids the common drift where an HTTP endpoint checks one set of rules while a background consumer checks a slightly different set.

Parallel evaluation is appropriate for independent validators, and Task.WhenAll evaluates them concurrently under the request’s cancellation scope. Avoid making a network call from every rule, and keep slow lookups out of the common path. For Australian deployments using Microsoft Azure, teams can place suitable workloads in the Australia East or Australia Southeast regions, then confirm that each dependent service supports the selected region; choosing a nearby region does not by itself guarantee residency for every piece of data.

Make failures predictable at each boundary

A pipeline is only useful if callers receive a consistent error shape. For an API, map ValidationException to HTTP 400 and return ValidationProblemDetails, with an errors collection keyed by request property. Include safe, human-readable messages, and use a correlation identifier for support conversations. A malformed JSON payload, a failed validation rule and a domain conflict are different conditions, so avoid folding all of them into one generic “bad request” response.

Transport-specific handling belongs at the edge. In a message consumer, a validation failure is normally not retryable because the payload will not become valid by trying again. Publish it to a dead-letter path with a reason code, or store it for correction, according to the business workflow. A transient database timeout is different and may justify retry with backoff. Keeping these decisions outside the behavior means the core validation remains usable by APIs, schedulers and queue processors.

Security and privacy deserve special attention. Do not return stack traces, validator internals or sensitive field values in an error response, and avoid logging full request objects by default. Australian financial, health and government workloads may also be subject to sector-specific obligations beyond the Privacy Act and Australian Privacy Principles. Apply data minimisation, redaction and retention rules to logs before releasing them to a managed observability platform, and keep business identifiers in secured operational tooling rather than user-facing error messages.

Test the contract and keep it maintainable

Start with fast unit tests for each validator, covering boundaries as well as obvious examples. For CreateCustomerRequest, that means empty values, an overlong name, malformed email addresses, and postcodes that are not four digits. Parameterised test cases keep the suite compact and make a rule change visible. These tests prove the rule itself; they do not prove that MediatR invokes it.

Integration tests should exercise the real registration and a representative request. Use WebApplicationFactory for an API or instantiate the service collection directly for a worker, then assert that an invalid request returns the expected problem details and that the handler is never called. Add a success-path test to confirm that validation does not consume or mutate the request, a multi-validator test to confirm that all failures are aggregated, and a cancellation test for slow rules. Mocking the handler’s side effects is useful, but testing the composition catches missing registrations and incorrect behavior ordering.

Treat the pipeline as an architectural boundary in code review. New commands should receive a validator when they accept external input, transport-specific endpoints should dispatch through MediatR rather than bypassing it, and failure mapping should remain at the edge. Telemetry can count validation failures by request type and error code without recording rejected payloads, giving teams a useful signal without collecting unnecessary personal information. A tested, centrally registered pipeline then becomes a dependable application guarantee rather than a convention that each developer has to remember.