Transaction Management With Mediator Pipelines in ASP.NET Core

Manage Entity Framework Core transactions when handling commands

When implementing a simplified CQRS service, which usually has a single database but still separates commands from queries, the mediator pipeline can be used to manage transactions when processing commands, ensuring changes will be implicitly committed unless an exception is thrown.

Implementing a pipeline for transactions has some key advantages even when using Entity Framework Core or other ORM that tracks and flushes changes at a single point in time.

Because the command handler is executing inside an implicit transaction, the developer is free to flush their changes as it sees fit knowing that any exception will rollback the changes. This is very helpful when it wants to cancel the flow when some business rules aren’t meet and could only be checked after changing the system state. Optimistic concurrency is a good example where you may want to flush your changes before leaving the handler so you know exactly what entity failed and can send a more detailed message to the user, which is the usual approach when implementing a dedicated Backend for Frontend service.

Read More

Validation with Mediator Pipelines in ASP.NET Core Applications

Validate commands, events or queries with transversal behavior

When implementing web applications that manipulate information, there is always the need to validate data sent by the clients, ensuring business rules are properly implemented.

Previously I talked about the implementation of Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) using a mediator pattern and how to support transversal behavior via pipelines.

In this article I’m going to demonstrate how validation can be enforced into your commands and events before reaching the handlers, making sure that invalid data will be rejected by the API.

Read More

Using Mediator Pipelines in ASP.NET Core Applications

Intercept commands, queries and events to apply transversal behavior

In my previous article I explained how you could implement Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) patterns using a mediator instance from SimpleSoft.Mediator in ASP.NET Core applications.

This time I’m going to explain how to intercept commands, queries and events, making it possible to apply transversal behavior before they reach the handlers, reducing significantly the amount of boilerplate and duplicated code.

Transaction management, logging, auditing, caching or validations are some of the good examples where pipelines can be very helpful. Imagine the following chains:

Read More

Mediator Pattern in ASP.NET Core Applications

Send commands, fetch queries, and broadcast events using a mediator pattern for CQRS+ES

For the last few years, Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) emerged as patterns that can help implement large scale systems, with some risky complexity, by having different models to read or mutate data while also using events as a single source of truth.

Since there are already great articles explaining CQRS or ES in great depth, I’m going to focus and show how you can decouple your application layers by only knowing POCOs and a mediator instance from SimpleSoft.Mediator.

Remember that, even if you are not using CQRS or ES to its full extend, just by ensuring a logical model segregation inside the project can make your life easier in the long run, even when implementing a simple Backend for Frontend (BFF) or a minimum viable product (MVP).

Read More