Interceptors allow you to step into an Entity Framework Core operation. By creating a concrete class that inherits from SaveChangesInterceptor can be powerful.
SaveChangesInterceptor exposes methods that allow you to modify the Saving process.
In our example we will create an application that stores information on Employees. The app will allow us to Create, Read, Update and Delete Employees. For simplicity we will use a SQLite database and DB Browser for SQLite to read the data.
A link to the supporting articles can be found below. 👇
Part #1: Using Interceptors With Entity Framework Core
.NET 8 has introduced Interceptors. Here’s how to use them to audit your database transactions.
Part #2: Using Interceptors With Entity Framework Core
Build out your endpoints and make requests using Swagger
Part #3: Using Interceptors With Entity Framework Core
Create an audit table & build the interceptor
To interact with this repo you will need to have .NET installed on your machine. You can download the latest .NET version here. This app is using .NET 8.
You can run the application by entering dotnet run at the root of the project.
Once the application is running you can append /swagger/index.html to the end of your port to interact with the endpoints using Swagger.
When an Employee entity is created via the POST "/employees" endpoint an EmployeeAudit entity is saved to the database.
However, as we are intercepting using SavingChangesAsync our Employee entity doesn't have an Id yet.
The Id is allocated after the save has completed. As a result, the EmployeeId in the EmployeeAudit entry is incorrect.
Also, the POST "/employees" and PUT "/employees" endpoints use the Employee object to build a request body.
As a result the Id field is exposed. In the future there should be a specific Request object to manage this instead
where the Id value is obfuscated.