Get Started with FluentValidation in ASP.NET 6: A Step-by-Step Guide

In this post, I’ll guide you through the process of getting started with FluentValidation in ASP.NET 6. FluentValidation is a powerful library for performing data validation in a fluent, expressive way, and it is especially well-suited to use in ASP.NET 6 projects.

I’ll show you how to set up FluentValidation in your ASP.NET 6 project and walk you through some examples of FluentValidation to validate different types of user input. By the end of this tutorial, you’ll understand how to use FluentValidation to ensure that your application receives accurate and reliable data. Let’s dive in!

Validation

Validation is the process of ensuring that some data is correct [1]. This can include checking that data is in the correct format, meets specific criteria, or is within certain boundaries. Validation is an essential step in any data-driven process, as it helps to ensure the integrity and reliability of the data being used.

Whether you are collecting data from users, importing data from external sources, or generating data within your application, it is essential to validate it to ensure that it is accurate and usable. Data errors can lead to incorrect results, poor decision-making, and many other problems without proper validation.

Demo — Validating Input

I created a simple API for creating a customer. I do not process the customer for the example. It is only about validation.

Let’s begin with creating a request class for the creation of a new customer.

public class CustomerCreateRequest
{
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

And then create a controller.

public class CustomerController : ControllerBase
{
    [HttpPost]
    public IActionResult CreateCustomer([FromBody] CustomerCreateRequest request)
    {
        return Ok();
    }
}

Of course, we could now validate the fields of the request class by some If queries, but this bloats the controller method. For this reason, we want to use FluentValidation. To do this, we must first install the package.

I created a folder for the validators to keep some order and created a CustomerCreateRequestValidator class containing the validation logic.

public class CustomerCreateRequestValidator : AbstractValidator<CustomerCreateRequest>
{
    public CustomerCreateRequestValidator()
    {
        RuleFor(x => x.Name).NotEmpty().Length(0,100);
        RuleFor(x => x.Email).NotEmpty().EmailAddress();
        RuleFor(x => x.Phone).NotEmpty().Matches(@"^\d{3}-\d{3}-\d{4}$");
    }
}

The class inherits from AbstractValidator with the type of the class to be validated. The validation then takes place in the validator class in the constructor.

I have checked various conditions, whether the field is empty and meets a certain length and format. Practically, these conditions can be read well. Also, the use of regex is possible.

Inside the controller method, we still need to perform this validation.

[HttpPost]
public IActionResult CreateCustomer([FromBody] CustomerCreateRequest request)
{
  var validator = new CustomerCreateRequestValidator();
  var validationResult = validator.Validate(request);

  if (validationResult.IsValid == false)
  {
      return BadRequest(validationResult.Errors[0].ErrorMessage);
  }

  return Ok();
}

The example project can be found on GitHub.

However, only the incoming data should be validated [1]. The primary business logic should be covered by unit tests [1].

Best Practices

• Name your validators after the data contracts they are validating [1]. This clarifies which validator should be used for a particular data contract and makes it easier to find and maintain the validator code.
• Use the built-in validation rules provided by FluentValidation where possible. These are well-tested and can be easily reused.
• Avoid duplicating validation logic across multiple validators. If multiple validators need to perform the same validation logic, extract that logic into a separate helper method that can be called from multiple validators.
• Use the RuleFor method to declare validation rules for a specific property of a data contract. This makes it straightforward to which property a validation rule applies.
• Use the When method to apply conditional validation rules. This allows you to change the validation logic based on the value of other properties in the data contract.

Domain Model vs. Data Contract

It is a best practice to separate the domain model from data contracts in an ASP.NET 6.0 project. The domain model represents the business logic and rules of the application, while data contracts are used to define the structure of data being passed between the client and server.

Keeping these two concerns separate allows for more flexibility and maintainability in the application. The domain model can evolve and change without affecting the data contracts. Changing or adding new data contracts does not affect the domain model.

This separation also makes it easier to unit test the domain logic, as it can be tested in isolation from the data contracts. Additionally, it can be easier to version the data contracts and handle backward compatibility.

Demo — Nested objects

Let’s assume our customers also has a field address, another class.

public class CustomerCreateRequest
{
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
    
    public Address Address { get; set; }
}

public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string ZipCode { get; set; }
}

How do we validate this? For this, we have to go back to our validator.

public class CustomerCreateRequestValidator : AbstractValidator<CustomerCreateRequest>
{
    public CustomerCreateRequestValidator()
    {
        RuleFor(x => x.Name).NotEmpty().Length(0,100);
        RuleFor(x => x.Email).NotEmpty().EmailAddress();
        RuleFor(x => x.Phone).NotEmpty().Matches(@"^\d{3}-\d{3}-\d{4}$");
        
        RuleFor(x => x.Address).SetValidator(new AddressValidator());
    }
}

public class AddressValidator : AbstractValidator<Address>
{
    public AddressValidator()
    {
        RuleFor(x => x.Street).NotEmpty().Length(0,100);
        RuleFor(x => x.City).NotEmpty().Length(0,100);
        RuleFor(x => x.State).NotEmpty().Length(0,100);
        RuleFor(x => x.ZipCode).NotEmpty().Length(0,100);
    }
}

We create another validator and set it. We do this because otherwise, we would have to check multiple times if the Address is not null. To avoid this duplicating code logic, we set another validator.

Conclusion

In conclusion, FluentValidation is a powerful tool for validating data in an ASP.NET 6.0 project. By following best practices such as naming validators after the data contracts they are validating, using built-in validation rules, avoiding duplication of validation logic, and applying conditional validation, developers can create maintainable and efficient validation logic.

Additionally, it is essential to separate the domain model from the data contracts to achieve more flexibility, maintainability, and testability in the application.

The two simple demos in this post demonstrate how FluentValidation can be used to validate data and how to handle nested object validation. By following the best practices and understanding the difference between data contracts and domain models, developers can create robust and effective validation logic in their applications.

Make sure to check out my other Posts!

Want to connect and stay up-to-date on AI, tech, and .NET development? 

Follow me on Twitter and LinkedIn - I'm always happy to hear from you.

References

1. FluentValidation Fundamentals By Vladimir Khorikov