Advanced validation rules

Complex validation rules in programming are an essential tool for accurately and precisely checking input data in an application. Their primary goal is to ensure that data entered by the user or received from other sources meet specific criteria, which are often more complicated than simple checks like the presence of a value or matching a pattern.

In more complex applications, where data is intricate and interconnected in various ways, the use of complex validation rules is necessary. For example, in a banking application where you conduct transactions, validation may require checking whether the user's account balance allows for the transaction or if the entered transaction data complies with other previously defined conditions. In such cases, simple rules, such as checking if a field is not empty, are insufficient.

Complex validation rules can include checking multiple conditions simultaneously, validation dependent on other values in the system, and even utilizing external services or databases to confirm data accuracy. This ensures greater security and precision in data management, which is crucial in applications with high complexity and significance.

Basic validation rules are usually simple checks, such as whether a text field is not empty, whether a number entered a field is within a specified range, or whether the format of an email address is correct. These are relatively easy to implement and understand, even for beginner programmers.

Complex validation rules go a step further. They may require checking several conditions at once, analyzing the interdependencies between different data, and even integrating business logic with data validation. For example, a rule might require that the value of one field be less than the value of another field (e.g., the start date must be earlier than the end date).

Such complex rules often require a deeper understanding of the business logic of the application and programming skills that enable their effective implementation. They frequently use more advanced programming techniques, such as lambda expressions, anonymous functions, and may also involve external data sources or services.

In practice, complex validation rules become essential in situations where the simplicity of basic rules cannot meet the requirements of the application. For example, in systems that manage large data sets with many interdependencies, or in applications where data-based decisions have significant financial or legal consequences, the precision and sophistication of validation are key.

In summary, understanding the difference between basic and complex validation rules and the ability to apply them is a crucial element in the arsenal of any programmer working on more complicated projects. This allows for the creation of applications that not only effectively manage data but also ensure its consistency, correctness, and safety.

Combining Validation Conditions

Combining several validation conditions for a single field is a key component of complex validation rules, allowing for more detailed scrutiny of input data. Imagine a scenario where we need to verify a text field, such as an email address. We want to ensure that this field is not only non-empty but also that the entered email address meets a specific format.

Suppose we have a UserRegistration class that includes an EmailAddress field. We want to verify that this field is not empty and contains a valid email address. Here’s how we might implement this:

using FluentValidation;

public class UserRegistration
{
    public string EmailAddress { get; set; }
}

public class UserRegistrationValidator : AbstractValidator<UserRegistration>
{
    public UserRegistrationValidator()
    {
        RuleFor(user => user.EmailAddress)
            .NotEmpty().WithMessage("Email address is required.")
            .EmailAddress().WithMessage("Invalid email format.");
    }
}

In the example above, the first step is to specify that our rule concerns the EmailAddress property in the UserRegistration class. We do this using the RuleFor method, passing it a lambda expression user => user.EmailAddress. This expression indicates that the validation rule we are about to define will pertain to the EmailAddress field of our user object representing an instance of the UserRegistration class.

We then move on to define the actual validation conditions. The first condition is NotEmpty, which aims to check whether the EmailAddress field is empty. This is a basic validation condition that ensures the field is not left without a value. If the field is empty, the FluentValidation mechanism automatically catches this and generates the error message "Email address is required," informing the user of the need to fill out this field.

The next validation condition is EmailAddress. This condition checks whether the value entered in the EmailAddress field conforms to the generally accepted email address format. It involves more than just checking if the field contains text; it verifies that this text is a structurally correct email address. If the format of the entered value is incorrect, the system reacts again by displaying the message "Invalid email format," which helps the user understand how to correct the entered data.

By combining these two conditions into one validation sequence, FluentValidation allows for the building of complex yet precise rules for checking the correctness of input data. This makes the process not only efficient but also clear and understandable both for developers and users of the application.

To illustrate the practical use of the UserRegistrationValidator we defined earlier, assume we have a simple application or scenario where a user needs to register by providing their email address. We will check if the given email address is correct, both in terms of being non-empty and meeting the standard email address format.

using FluentValidation;
using System;

public class Program
{
    public static void Main(string[] args)
    {
        var userRegistration = new UserRegistration
        {
            EmailAddress = "email@example.com"
        };

        var validator = new UserRegistrationValidator();
        var validationResult = validator.Validate(userRegistration);

        if (validationResult.IsValid)
        {
            Console.WriteLine("Registration successful!");
        }
        else
        {
            foreach (var error in validationResult.Errors)
            {
                Console.WriteLine(error.ErrorMessage);
            }
        }
    }
}

In the example above, we start by creating an instance of the UserRegistration class, to which we assign a sample email address, thus simulating the process of a user entering data. Next, we create an instance of the UserRegistrationValidator and use its Validate method, passing our userRegistration object to check the data’s correctness. The Validate method returns a validationResult object containing information about the outcome of the validation. We check if the validation was successful (i.e., if validationResult.IsValid is true). If the outcome is positive, we display a message of successful registration. Otherwise, we go through the list of validation errors, listing each one so that the user can appropriately respond to the issues encountered.

The "Must" Method

In software development, especially in the context of data validation, flexibility and dynamism are key. This is where predicates in FluentValidation demonstrate their strength, enabling the creation of complex validation rules that can adapt to a variety of scenarios and input data. A predicate is a function that takes one or more arguments and returns a boolean value, indicating whether a specific condition is met.

In FluentValidation, the Must method allows the inclusion of custom predicates into the validation process. With this method, you can define your own logical conditions that must be met for the data to be considered valid. Moreover, these predicates can utilize external context, allowing for the creation of rules that dynamically adjust to current data or the state of the application.

An example of using predicates might be validating a user model where password strength requirements depend on the user's assigned role. In a simple user model, you might have a Password field and a Role field. Depending on the role, the requirements for the password might differ—for instance, administrators might need longer and more complex passwords than regular users.

Here is a sample implementation of such logic:

public class UserValidator : AbstractValidator<User>
{
    public UserValidator()
    {
        RuleFor(user => user.Password)
            .Must((user, password) => BeAValidPassword(user, password))
            .WithMessage("The password does not meet security requirements.");
    }

    private bool BeAValidPassword(User user, string password)
    {
        if (user.Role == Role.Admin)
        {
            return password.Length > 10 && HasSpecialCharacters(password);
        }
        else
        {
            return password.Length > 6;
        }
    }

    private bool HasSpecialCharacters(string input)
    {
        string specialCharacters = "!@#$%^&*()_-+={[}]|:;<,>.?/";
        return input.Any(ch => specialCharacters.Contains(ch));
    }
}

In this case, the method BeAValidPassword is a predicate used in the Must method. With access to the entire User object, the predicate can adjust its requirements depending on the user's role, illustrating the dynamics and flexibility of validation.

Predicates in C# and the FluentValidation library offer broad capabilities for creating complex and sophisticated validation rules. Due to their flexibility, they can be applied in various, complicated scenarios, including validation of collections.

For collection validation, predicates can be an invaluable tool for checking whether elements of the collection meet specified criteria. FluentValidation allows for easy implementation of such conditions. For example, if you have a collection of objects and want to ensure that each object meets certain conditions, you can use the Must method in conjunction with LINQ methods such as All or Any.

RuleFor(user => user.Tasks)
    .Must(tasks => tasks.All(task => task.IsCompleted))
    .WithMessage("All tasks must be completed.");

In this case, for a User model with a collection of Tasks, we check whether all tasks have been completed. The All method will return true only if every task in the collection meets the condition task.IsCompleted.

Using predicates in this way not only enhances the capabilities of validation but also makes the code more modular and easier to maintain, as the validation logic is clearly separated from other parts of the application.

Conditional Rule Definition

The When and Unless methods can be used to conditionally define rules that control when a rule should be executed. They allow for conditional application of validations, making validation not only more flexible but also more aligned with real business requirements. On the other hand, Otherwise offers a way to define an alternative validation path to be applied when the condition specified in When is not met. This approach allows for clear and organized validation logic that can handle various scenarios and use cases. Using these methods in FluentValidation enables the construction of complex validation rules in a manner that is both efficient and understandable for those developing and maintaining the code.

When used in a validation rule allows for the conditional application of that rule. It can be likened to using an if statement in traditional programming. If the condition specified in When is met (returns true), then the validation rule is applied. Otherwise, the rule is skipped.

Example of using When in a rule:

RuleFor(user => user.Password)
    .MinimumLength(8)
    .When(user => user.IsPasswordChangeRequired);

In this example, the rule requiring a minimum of 8 characters for the user's password is applied only when the user has the flag IsPasswordChangeRequired set to true. This allows for flexible validation that adapts to specific business needs.

When can also be used as a separate statement, independent of a specific validation rule, defining a conditional block in which multiple rules can be placed. This approach allows for the grouping of multiple rules that are to be applied only when a specified condition is met.

Example of using When as a separate statement:

When(user => user.IsPasswordChangeRequired, () =>
{
    RuleFor(user => user.Password)
        .MinimumLength(8)
        .Matches("[A-Z]")
        .Matches("[0-9]");
});

In this example, When defines a conditional block where we place three rules regarding the password. All these rules — requiring a minimum of 8 characters, at least one uppercase letter, and at least one digit — are applied only when the condition user.IsPasswordChangeRequired is met. This is particularly useful when we have a set of rules we want to apply in specific situations, avoiding redundancy and enhancing code readability.

Similar to When, the Unless directive in Fluent Validation provides a mechanism for the conditional application of validation rules. However, unlike When, Unless applies the validation rule only when the specified condition is not met. In other words, Unless works on the principle of condition negation — if the condition returns false, then the validation rule is applied.

Example of using Unless in a rule:

RuleFor(user => user.DateOfBirth)
    .Must(BeAValidAge)
    .Unless(user => user.IsSpecialMember);

In this example, the validation rule, which requires that the user's age be appropriate (e.g., adult), is applied to all users unless the user is marked as IsSpecialMember. Thanks to Unless, we can easily exclude certain objects from general rules without the need for writing complex logic.

Like When, Unless can also be used as a separate statement, defining a block in which we specify rules that are to be omitted if the condition is met.

Example of using Unless as a separate statement:

Unless(user => user.IsSpecialMember, () =>
{
    RuleFor(user => user.DateOfBirth)
        .Must(BeAValidAge);
    RuleFor(user => user.AccountBalance)
        .GreaterThan(0);
});

In this example, Unless defines a conditional block where we place rules concerning the date of birth and account balance. These rules will be applied only if the user is not marked as IsSpecialMember.

Otherwise in Fluent Validation allows for defining rules that are to be applied when the condition specified in When is not met. This provides a clear and organized structure for validation, where it is easy to define what happens in different scenarios.

Example of using When with Otherwise:

When(customer => customer.IsPreferred, () => {
    // These rules are applied only for preferred customers
    RuleFor(customer => customer.CustomerDiscount).GreaterThan(0);
    RuleFor(customer => customer.CreditCardNumber).NotNull();
}).Otherwise(() => {
    // These rules are applied when the customer is not preferred
    RuleFor(customer => customer.CustomerDiscount).Equal(0);
});

In this example, for preferred customers, we check if their discount is greater than 0 and if they have a credit card number. However, if the customer is not preferred (i.e., the condition customer.IsPreferred is not met), then an alternative validation rule is applied, checking if the customer's discount is equal to 0.

The methods When, Unless, and Otherwise in Fluent Validation offer powerful and flexible tools for creating conditional validation rules, allowing precise adjustment of the validation process to specific business requirements. When enables the application of rules only when specific conditions are met, while Unless works oppositely, applying rules only when a condition is not met. Meanwhile, Otherwise introduces an alternative validation path that is used when conditions specified in When are not met. The collaboration of these three mechanisms allows for building complex and well-organized validation processes that are capable of effectively managing diverse scenarios and requirements, ensuring high readability and ease of maintenance.

Validation Messages in FluentValidation

Overriding default error messages in FluentValidation allows customization of validation to fit the specific context of the application, making the messages more understandable for the user. Using the WithMessage method, you can define your own messages, which significantly enhances the user experience.

RuleFor(user => user.Email)
    .EmailAddress()
    .WithMessage("Please provide a valid email address.");

FluentValidation also offers the possibility of using placeholders. Overriding the default error messages in FluentValidation with placeholders allows for creating dynamic and contextual messages that automatically adjust to the specific case of validation. Placeholders such as {PropertyName} or {PropertyValue} enable the insertion of the name of the validated property or its value directly into the error message. Each validator has a list of available placeholders, which allows for precise message customization.

For example, in comparison validators (such as Equal, GreaterThan), you can use {ComparisonValue} to display the value with which the property is compared, and in the length validator (Length), placeholders such as {MinLength}, {MaxLength}, or {TotalLength} are available.

Example with placeholder:

RuleFor(user => user.Age)
    .GreaterThan(18)
    .WithMessage("{PropertyName} must be greater than 18. Current value: {PropertyValue}");

In this case, if the validation fails, the error message will include the property name (Age) and the value that failed the validation, making the message more precise and informative.

FluentValidation also offers the possibility to create more complex error messages, which can include values from the model itself or from the validation context. This can be done using methods such as WithMessage, providing a function that returns a string as an argument.

Example:

RuleFor(user => user.Age)
    .GreaterThan(18)
    .WithMessage(user => $"User must be older than 18 years. Provided age: {user.Age}");

In this case, if the age validation fails, the user will receive a detailed message, including the information about the actual age provided.

Thanks to the ability to override messages and use placeholders, FluentValidation allows for the creation of clear and helpful error messages that make it easier for users to understand what went wrong and how they can correct the error.

Complex validation rules are crucial in advanced applications, ensuring accuracy, security, and consistency of data. These rules enable developers to effectively manage complex conditions and dependencies, which are essential in systems with a high degree of complexity. Applying these rules helps avoid errors and ensures high-quality application performance.

See you in upcoming posts.