FluentValidation is a popular .NET library for building strongly-typed validation rules for models in a clean and maintainable way. Unlike traditional validation methods, FluentValidation provides a fluent API, making validation rules more readable, maintainable, and reusable. It integrates well with ASP.NET Core and can be used to validate models in APIs, MVC applications, and other .NET projects.
With FluentValidation, you can define validation rules in a separate class instead of cluttering your models with attributes. It supports various validation features like:
- Conditional validation (rules that apply based on certain conditions)
- Custom validators (defining your own validation logic)
- Rule chaining (combining multiple validations on a single property)
- Localization (support for multiple languages)
- Dependency Injection support (for validation in ASP.NET Core APIs)
- Integration with ASP.NET Core’s validation pipeline
Example Usage
To use FluentValidation, first install the NuGet package:
|
1 |
Install-Package FluentValidation.AspNetCore |
Create a model that needs validation:
|
1 2 3 4 5 6 |
public class UserModel { public string Name { get; set; } public string Email { get; set; } public int Age { get; set; } } |
Next, create a validator class:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
using FluentValidation; public class UserModelValidator : AbstractValidator<UserModel> { public UserModelValidator() { RuleFor(user => user.Name) .NotEmpty().WithMessage("Name is required"); RuleFor(user => user.Email) .NotEmpty().WithMessage("Email is required") .EmailAddress().WithMessage("Invalid email format"); RuleFor(user => user.Age) .GreaterThan(0).WithMessage("Age must be greater than zero"); } } |
Registering FluentValidation in ASP.NET Core
In the Program.cs file, register FluentValidation services:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
using FluentValidation; using FluentValidation.AspNetCore; var builder = WebApplication.CreateBuilder(args); // Add services to the container. builder.Services.AddControllers(); builder.Services.AddValidatorsFromAssemblyContaining<UserModelValidator>(); var app = builder.Build(); app.UseAuthorization(); app.MapControllers(); app.Run(); |
Then, use dependency injection to validate your models inside controllers:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
[ApiController] [Route("api/users")] public class UsersController : ControllerBase { private readonly IValidator<UserModel> _validator; public UsersController(IValidator<UserModel> validator) { _validator = validator; } [HttpPost] public IActionResult CreateUser([FromBody] UserModel user) { var validationResult = _validator.Validate(user); if (!validationResult.IsValid) { return BadRequest(validationResult.Errors); } return Ok("User created successfully"); } } |
I think you’re thinking that, We can achieve this using DataAnnotations, so why is FluentValidation necessary?
You’re absolutely right that DataAnnotations can also be used for validation in .NET Core. However, FluentValidation provides several advantages over DataAnnotations, making it a better choice in many scenarios. Let’s compare both and discuss why FluentValidation is preferred.
Comparison: DataAnnotations vs. FluentValidation
| Feature | DataAnnotations | FluentValidation |
|---|---|---|
| Separation of concerns | Validation is mixed with model properties using attributes. | Validation logic is kept in a separate class, making it more maintainable. |
| Complex validation logic | Hard to implement complex rules. | Supports conditional and rule-based validation easily. |
| Multiple rules per property | Limited flexibility, requires workarounds. | Supports chaining multiple rules on a single property. |
| Custom validation | Requires custom attributes. | Easily define custom validation logic inside validators. |
| Localization | Limited support. | Built-in support for multilingual error messages. |
| Dependency Injection (DI) support | Not directly supported. | Fully supports DI for API validation. |
| Better readability | Can be cluttered with many attributes. | Rules are clearly structured in separate classes. |
Why Choose FluentValidation Over DataAnnotations?
Here are the main reasons:
1. Separation of Concerns (Cleaner Models)
With DataAnnotations, validation logic is mixed inside the model, making it harder to maintain:
|
1 2 3 4 5 6 7 8 9 |
public class UserModel { [Required(ErrorMessage = "Name is required")] [StringLength(50, MinimumLength = 3, ErrorMessage = "Name must be between 3 and 50 characters")] public string Name { get; set; } [Range(1, 100, ErrorMessage = "Age must be between 1 and 100")] public int Age { get; set; } } |
Using FluentValidation, validation rules are separated into another class, keeping the model clean:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
public class UserModel { public string Name { get; set; } public int Age { get; set; } } public class UserValidator : AbstractValidator<UserModel> { public UserValidator() { RuleFor(user => user.Name) .NotEmpty().WithMessage("Name is required") .Length(3, 50).WithMessage("Name must be between 3 and 50 characters"); RuleFor(user => user.Age) .InclusiveBetween(1, 100).WithMessage("Age must be between 1 and 100"); } } |
2. Supports Complex Validation Rules
If a user should be at least 18 years old only if their role is ‘Admin’, it’s difficult to implement in DataAnnotations but simple in FluentValidation:
|
1 2 3 |
RuleFor(user => user.Age) .GreaterThanOrEqualTo(18).When(user => user.Role == "Admin") .WithMessage("Admins must be at least 18 years old"); |
With DataAnnotations, you would need to write a custom attribute, which is more complex and less reusable.
3. Better Custom Validation
With FluentValidation, you can define custom validation rules easily:
|
1 2 3 |
RuleFor(user => user.Email) .Must(email => email.EndsWith("@gmail.com")) .WithMessage("Only Gmail addresses are allowed"); |
With DataAnnotations, you would have to create a custom attribute class, which is more effort.
4. Error Messages & Localization
FluentValidation allows dynamic localization, while DataAnnotations requires static messages:
|
1 2 |
RuleFor(user => user.Name) .NotEmpty().WithMessage(LocalizationResources.NameRequired); |
This is useful for applications that support multiple languages.
5. Dependency Injection & Testing
FluentValidation supports dependency injection (DI), making it better for API development. It allows injecting services into the validator, for example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public class UserValidator : AbstractValidator<UserModel> { private readonly IUserService _userService; public UserValidator(IUserService userService) { _userService = userService; RuleFor(user => user.Email) .MustAsync(async (email, cancellation) => !await _userService.EmailExists(email)) .WithMessage("Email is already in use"); } } |
With DataAnnotations, you cannot inject services into validation logic.
When Should You Use FluentValidation?
FluentValidation is the better choice when:
- Your validation logic is complex (conditional validation, custom rules).
- You want clean models with separated validation logic.
- Your project requires dependency injection for validation.
- You need dynamic/localized error messages.
- You want better maintainability and testability.
Use DataAnnotations only for simple validation in small projects. FluentValidation is a more powerful and flexible alternative to DataAnnotations, especially in large applications where maintainability, testability, and complex validation logic are required. Would you like help integrating FluentValidation into your project?
Leave a Comment