In this article, we’ll configure ASP.NET to open a single transaction per request and commit it when the request finishes.
Most APIs work with DB under the hood, and It’s bad practice to commit changes separately a few times during HTTP requests. It can cause a lot of round trips to the database just for one HTTP request. Also, it leads to corrupted data if something goes wrong. The Best approach would be to open a single transaction and only when everything goes well commit the transaction. In such a case, we appreciate data integrity, and if something goes wrong with that transaction, we can revert all changes.
Let’s review an example which related to the real world. Assuming that we have an application with a data layer where we enclose all work with data. I’ll use EntityFramework (EF) as ORM for the database in my example. It doesn’t matter what kind of database to use. We’ll skip everything and concentrate on general logic for a single transaction for simplicity.
Let’s define an example DB context:
public class ExampleContext : DbContext
It was intentionally left empty because, in our example, we don’t care about what happens inside context.
We need to define an attribute that allows handling all DB change requests in a single transaction. It’s our responsibility to use the next attribute and mark proper actions with a single transaction. We can’t add a global filter because some actions use DB context in read-only mode, and we don’t need to define any transaction.
public class SingleTransactionAttribute : ActionFilterAttribute
In a SingleTransactionAttribute, we override the OnActionExecutionAsync method. It allows us to add behavior before and right after the action is executed. We need to begin a new transaction before action execution, and when the action completes without errors, we need to commit the transaction.
Also, as you see, put SaveChangesAsync in this attribute. In order to skip calling it all around the code, we have a single place where we save all changes and commit the transaction. Our business logic code knows nothing when to invoke SaveChangesAsync.
Such assumption strongly relies on the Object tracking mechanism under the hood of EntityFramework, but it’s a topic for another story.
Take a look at basic EntityFramework knowledge
Besides this attribute, we also need to configure Dependency Injection to make a scope per user request and provide a single DbContext instance during the scope:
Here is an example of how to do it during application startup. We add both DbContext and SingleTransactionAttribute to the service as scoped items. And rely on default ASP.NET behavior to use the client request as a scope.
I hope this article was useful for someone.