Using the Mediatr pipeline with Fluent Validation

This post details the basic setup steps required to implement server side validation using pipeline behaviour native to Mediatr with the Fluent Validation package.

Configuration

•  Install the FluentValidation NuGet package (Project URL) into both the Mediatr project and the project where the IOC is initialised e.g the Engine project
• Create a ValidationBehavior file, in the Mediatr project

•  Register collections for IValidator and IPipelineBehaviour in the IOC initialisation. Note that IValidator uses FluentValidation and IPipelineBehaviour uses Mediatr

Validator Setup

• Add a validator into the Mediatr  project. The FluentMigration package enables the validator to implement AbstractValidator, as well as calling RuleFor(). In the example below, the validator is ensuring that there are no dogs added without a name. If a user attempts to do so, the error message "Dog has no name" will return -  the request will not be completed, and so the dog without a name will not be added to the database.

• Additions can be made to the validator, to also ensure that the dog's owner exists. Using the Must() method, the OwnerId from the request can be passed into the custom OwnerExists() method which calculates if an owner exists in the database with the OwnerId in the request. If OwnerExists() returns false then the error message "Owner does not exist" will return, and the request will not add the dog into the database

• Sometimes it only makes sense only to run a rule if a preceding rule passes. For instance, if the owner does not exist, then it does not make sense to check if that owner has a valid contact number. The DependentRules() method can be used to create rules that depend on another rule

Conclusion

This post has briefly detailed the setup procedure for using the mediatr pipeline with fluent validation for the purposes of server side validation. There are several positives to this method of server side validation. It is easy to setup, and quick to implement good validation. In addition, there is no need to have separate files for every rule/exception, as all the validation for a request fits neatly onto 1 file; making the project more manageable. 

However, I have come across a notable drawback. Validators for requests that return void will not run! To solve, I use a dirty workaround wherein I make all void requests return an unused arbitrary integer. Despite this, my experience with fluent validation has been largely positive, and I will look to implement it again in future projects.