Building a modern API? Don’t let your validation logic spiral into an unmaintainable mess. Combine the power of FluentValidation and a Global Filter to enforce clean, testable rules and return consistent, user-friendly error responses.

Let’s break it down 👇

🔄 Request Lifecycle – Validation Flow

graph TD
  A[Client Request] --> B[Model Binding]
  B --> C[FluentValidation]
  C -->|Validation Fails| D[Global Error Filter]
  D --> E[Formatted Error Response]
  C -->|Validation Passes| F[Controller Action]
  F --> G[Success Response]

🔍 Why Use Both FluentValidation + Global Filter?

Layer	Purpose
✅ FluentValidation	Clean, reusable, testable rules (separated from domain/UI logic)
✅ Global Filter	Centralized formatting of validation errors for consistency
❌ Data Annotations	Inline and tightly coupled — not ideal for scalability/testability
✅ Custom Logic	Useful for DB lookups, async rules, and cross-field validations

🧩 Think of It Like This

FluentValidation → What to validate?
e.g. .NotEmpty(), .Must(...), .GreaterThan(...)

Global Filter → How to respond?
Format errors like this:

  {
    "success": false,
    "errors": [
      { "field": "Type", "message": "Invalid bus type" }
    ]
  }

Custom Validation → Complex checks?
Ideal for service/DB-based or async validation rules
Data Annotations → Quick & dirty
Avoid mixing validation with models in scalable apps

🛠 Best Practice Cheatsheet

Concern	Best Tool
Field-level validation	✅ FluentValidation
Cross-property logic	✅ FluentValidation
Uniform error output	✅ Global Filter (IActionFilter/Middleware)
Async/complex logic	✅ Custom Validators or Middleware
One-off inline rules	❌ Avoid Data Annotations

⚠️ Why NOT Use Just One?

❌ FluentValidation Alone?

Default output:

{
  "errors": {
    "field": ["Some error message"]
  }
}

No success: false, no flattened format, no UX consistency.

❌ Only Global Filter?

Manually writing validations = Repetitive, fragile code.

❌ Data Annotations?

❌ Hard to test
❌ No DI
❌ Mixes concerns
❌ Poor for complex rules

✅ Real Example: FluentValidation + Global Filter

BusValidator.cs

public class BusValidator : AbstractValidator<Bus>
{
    private static readonly List<string> AllowedTypes = new() { "Mini", "DoubleDecker", "Electric" };

    public BusValidator()
    {
        RuleFor(x => x.BusName)
            .NotEmpty().WithMessage("Bus name is required");

        RuleFor(x => x.Type)
            .Must(type => AllowedTypes.Contains(type))
            .WithMessage("Invalid bus type");
    }
}

Global Filter Output

{
  "success": false,
  "errors": [
    { "field": "Type", "message": "Invalid bus type" }
  ]
}

🧪 Unit Test Example (xUnit + FluentValidation.TestHelper)

public class BusValidatorTests
{
    private readonly BusValidator _validator = new();

    [Fact]
    public void Should_Have_Error_When_BusName_Is_Empty()
    {
        var model = new Bus { BusName = "", Type = "Mini" };
        var result = _validator.TestValidate(model);
        result.ShouldHaveValidationErrorFor(x => x.BusName);
    }
}

✅ Final Comparison – When to Use What?

Validation Type	Use It?	Why
FluentValidation	✅ Yes	Clean, testable, supports DI
Global Filter	✅ Yes	Centralized error formatting
Custom Validation	✅ Yes	Async logic, DB lookups, cross-entity rules
Data Annotations	❌ No	Obsolete in scalable architecture

🚀 Wrapping Up

Combining FluentValidation + Global Filter gives you:

✅ Clean separation of concerns
✅ Predictable, consistent client responses
✅ Maintainable and testable validation logic

📌 This pattern is a must-have for any professional .NET Web API project!

💡 Bonus Tip: Middleware Over Filters?

Prefer middleware? You can handle validation globally via middleware too — ideal for advanced async or cross-cutting rules.
✉️ Drop a comment if you'd like to see that version!

🧼 Clean API Validation in .NET – FluentValidation + Global Filter Done Right