For the recipes in this chapter, you’ll need the following:

• Git: Make sure you have Git installed.
• .NET 9 SDK: The .NET 9 SDK is available here: https://dotnet.microsoft.com/en-us/download/dotnet/9.0.
• DB Browser for SQLite: Unlike Chapter 1, where we used the in-memory SQLite provider for EF Core, this chapter will use a real SQLite database that persists to disk. SQLite works with a single file rather than connecting to a server with a connection string. SQLite, due to its simplicity, allows you to concentrate on understanding validation best practices without the extra layers of checks and guardrails seen in databases such as Microsoft SQL Server. It can be helpful to view the database we will be creating with DB Browser for SQLite, which is available here: https://sqlitebrowser.org/.
• A note on mappers: The projects in this chapter use both EF Core and Dapper. Please check the GitHub end projects folder to see the full Dapper versions...

We will start by exploring the simplest form of model validation in ASP.NET Core – model validation using data annotations.

Data annotations allow you to decorate model properties with attributes that specify validation criteria. This ensures that the data received from the user adheres to defined rules and formats, preventing invalid data from causing errors or inconsistencies. By utilizing data annotations, we can also provide more specific feedback when a client POSTs data that does not conform to the model’s properties. This technique is a lot better than returning a vague generic error message to the client. Instead of returning a generic error, this approach guides the client on what properties need to be modified to meet the required criteria.

In this recipe, we will use DataAnnotations to apply model validation. The starter project for this chapter is a Web API with two controllers. Both controllers have one endpoint...

In this recipe, we will create our own custom validation attribute to validate incoming data to our API. We will also learn how to retry model binding with TryValidateModel.

Getting ready

This recipe picks up where the preceding recipe left off. You can find a starter project here: https://github.com/PacktPublishing/ASP.NET-9-Web-API-Cookbook/tree/main/start/chapter02/CustomAnnotations

How to do it…

1. Create a new custom validation attribute class in the Models folder, which inherits from ValidationAttribute:

   using System.ComponentModel.DataAnnotations;
   namespace CustomAnnotations.Models;
   public class AllowedValuesAttribute : ValidationAttribute
   {
       private readonly List<string> _allowedValues;
       public AllowedValuesAttribute(params string[] allowedValues)
       {
           _allowedValues = allowedValues?.ToList() ?? new...

In this recipe, we will implement custom validation logic in our DTO class using IValidateObject. This will allow us to create validation logic for an entire model instead of only one property.

Getting ready

The starting code for this project resides here: https://github.com/PacktPublishing/ASP.NET-9-Web-API-Cookbook/tree/main/start/chapter02/IValidateObject.

How to do It…

1. Modify your existing EventRegistrationDTO to inherit from IValidateObject:

   using System;
   using System.Collections.Generic;
   using System.ComponentModel.DataAnnotations;
   namespace events.Models
   {
       public class EventRegistrationDTO : IValidatableObject
       {
       …

2. Create the Validate method, which yields a ValidationResult if the date is not in the future:

   public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
       ...

In this recipe, we will learn how to create complex validation rules using the FluentValidation library. FluentValidation offers a more fluent and flexible way to define validation logic.

Getting ready

We are going to continue working with the same DTO. However, all the validation rules have been removed – both the simple data annotations and the rules created via IValidateObject. The code for this project resides here: chapter02/FluentValidation.

How to do it…

1. Open the project in Visual Studio Code.
2. Open the terminal and type dotnet run.
3. Open the browser and go to http://localhost:5217/scalar/chapter2.

   You have a basic API with some DataAnnotations and a custom DataAnnotations attribute on the DTO.

4. Install the FluentValidation NuGet package:

   dotnet add package FluentValidation.AspNetCore

5. Note that our DTO currently has no validation rules. Add the following code to the EventRegistrationDTO...

This recipe will demonstrate how to update an existing resource using PUT requests. Proper handling of resource updates is crucial for maintaining data integrity. For this task, you will learn how to use AutoMapper, a popular object-to-object mapping library. AutoMapper facilitates the mapping between Data Transfer Objects (DTOs) and entity models. AutoMapper also helps us reduce the boilerplate code needed for manual property mapping.

Getting ready

The repository is available here: https://github.com/PacktPublishing/ASP.NET-9-Web-API-Cookbook/tree/main/end/chapter02/AutoMapper. This starter project is different from the one we left off with, so it is crucial that you clone it if you want to follow along. The starter project includes an AdditionalContactInfo model for storing secondary contact details, which we’ll be mapping alongside our main EventRegistration model.

How to do it…

1. Clone the repository using...

In this recipe, we will leverage our AutoMapper setup to implement the deletion of EventRegistration and its dependent entity, AdditionalContact. This ensures that when EventRegistration is deleted, its related AdditionalContact information is also handled.

Getting ready

The starting code for this project is found here: https://github.com/PacktPublishing/ASP.NET-9-Web-API-Cookbook/tree/main/start/chapter02/CascadeDelete. This recipe picks up where the preceding recipe ended.

How to do it…

1. Add the DELETE endpoint to your controller. In your EFEventsController, let’s get started by adding the following attributes for a new DELETE endpoint:

   [HttpDelete("{id}")]
   [EndpointSummary("Delete an existing event registration")]
   [EndpointDescription("DELETE to remove an existing event registration.")]
   [ProducesResponseType(StatusCodes.Status200OK)]
   [ProducesResponseType(StatusCodes.Status404NotFound...

Using a PATCH request, we can update specific fields of a data entity (resource) without sending the entire object to the endpoint. In this recipe, we will leverage the JsonPatchDocument library to target and modify only the fields you need to change. This approach ensures minimal data transfer and precise updates to your resources.

Getting ready

The code for the starter project resides here: chapter02\start\JsonPatchDocument. This recipe picks up where the previous one left off.

How to do it…

1. First, install the required packages:

   dotnet add package Microsoft.AspNetCore.JsonPatch
   dotnet add package Microsoft.AspNetCore.Mvc.NewtonSoftJson

   We are not going to use System.Text.Json as our JSON provider in this example. Although it is possible to set up JsonPatch with System.Text.Json, it is more work. Import the Mvc.Formatters namespace and register that you would like to use Newtonsoft for Json on our...