Introduction

In this post we are going to look at adding validation to the code we worked on in Part 6. We will use active patterns that we looked at in the last post (Part 7) and we will see how you can easily model domain errors.

Setting Up

We are going to use the code from Part 6.

Solving the Problem

The first thing we need to do is create a new record type that will store our validated data. Add this type below the Customer type definition:

Have a look at the source data to understand why some of the parts are optional.

We now need to add a new helper function to create a ValidatedCustomer:

Now we need to think about how we handle validation errors. The obvious choices are using Option but then we lose the reason for the error or Result but that is going to make using our new create function difficult to use; We will use Result. The other thing we need to consider is what types of errors do we expect. The obvious ones are missing data (empty string) or invalid data (string to DateTime/decimal/boolean). We also want to return all of the errors, not just the first one, so we need a list of errors in the output. Lets create the error type as a discriminated union with tupled data:

For missing data, we only need the name of the item but for invalid data, we want the name and the value that failed.

Now we will create some helper functions using active patterns to handle empty string, email regex and booleans:

You will need to add 'open System.Text.RegularExpressions' in the declarations at the top of the file.

Now lets create our validate functions using our new ValidationError discriminated union:

We now need to create a validation function. Notice that I have added the expected return type:

As noted earlier, we now have a problem - The create function isn't expecting Result types. With the skills and knowledge that we have from this series, we can solve this but not in a very elegant way!

Firstly, we create a couple of helper functions to extract Error and Ok data:

Now we create a list of potential errors, concatenate them and then check to see if there are any:

Finally, we need to plug the validation into the pipeline:

If you run the code using 'dotnet run', you should get some typed data as output.

If you want to see how we can solve this in a more idiomatically functional way, have a look at my post on Functional Validation in F# Using Applicatives that I did for the 2019 F# Advent Calendar.

Final Code

This is what you should have ended up with:

Conclusion

In this post we have looked at how we can add validation by using active patterns and how easy it is to add additional functionality into the data processing pipeline.

In the next post we will look at improving the code from the first post we worked on by using more domain terminology.

If you have any comments on this series of posts or suggestions for new ones, send me a tweet (@ijrussell) and let me know.