CQRS and Event sourcing in ASP.NET [Explained]

CQRS (Command-Query Responsibility Segregation) is a pattern commonly used with event sourcing pattern. Command-query responsibility segregation-based system to use the data model to read and write.

By implementing, Command-query responsibility segregation (CQRS) can maximize performance, scalability, and security for your application. Event-sourcing is used to store data models with an action taken on data instead of storing the current data state.

Also Read: How to create ASP.NET Registration Form Using C# and SQL Server Database

What is CQRS (Command-Query Responsibility Segregation)?

Command-Query Responsibility Segregation (CQRS) is a design pattern that has huge consequences for any system design. CQRS states that command and query are completely different things and are executed against the different model (Read model and write model) of data.

The Command-Query Responsibility Segregation pattern divides into two categories:

Queries (Return Data): Get data/information from the database and never modify anything within the model.

Commands (Perform Action): Command performs the action which can be written, update, delete (along with business logic).

In traditional architectures, the common data model is used to read and update a database and perform CRUD operation.  In complex applications on the read-side, the application performs different queries, and object mapping can become complex.

For the write-side, the model implements complicated validation and business logic for the application.

Also Read: How To Create ASP.net Login Page Using C# with SQL Database [Download]

Challenges without CQRS

• There may be a mismatch between the read and write representations of the data because of additional columns or properties that must be updated correctly, even though they aren’t required as part of an operation.
• The traditional approach can hurt performance because of the load on the data store and data access layer, and the complex queries are used to retrieve information.
• The traditional approach uses a common entity for reading and writes operation, so managing security and permissions can be complex.

Also Read: 15 Best App Review Sites 2020

Solution

CQRS uses a separate read and writes model, Command is used to update data, and Queries is used to read data.

• The command should not base on data. It should be task-based.
• The command should be placed in an asynchronous queue rather than being processed synchronously.
• Query can’t modify the database and return DTO (Data transfer object).

Benefits of CQRS

The benefits of CQRS are as follow:

• Independent scaling: For scaling independently, CQRS allows the read and write workloads.
• Optimized data schemas: Schema is used by the read side to optimize the query, and Schema is used by the write side to optimize updates.
• Separating read and write side: By separating, the read and write sides can result in models to be maintainable and flexible. Write models contain complex business logic, and the read model can be simple.
• Simpler queries: Using a materialized view in the read database, the application can avoid complex joins when querying.
• Performance: CQRS increases performance because the event is store in serialized JSON, and re-run JSON is fast.

Also Read: 6 Best Free Soundboard Software For Windows [2020]

What is Event sourcing?

In a “normal” database, data is store as exists at the moment with its value and relation. In the Event Sourcing data store, data is a store with its changes in the form of an event. These events can be re-run later to re-create the current state of data.

In Event sourcing, you have data stored at the current point in time and can re-create the data-store at any time. Event sourcing can improve the performance, scalability, and responsiveness of an application.

Command-Query Responsibility Segregation and Event sourcing fit so well together because event sourcing becomes a write model of CQRS while the read model’s design is irrelevant.

CQRS and ES system work well together, and the CQRS/ES system label is just a CQRS system.

CQRS/ES system is difficult to set up.

Why use Command-Query Responsibility Segregation/Event sourcing?

Use CQRS if:

• CQRS/ES is used when performance is a major concern in your application.
• If your application required all the data at any point in time.

When to use this pattern?

Consider the following scenarios for CQRS:

• When a collaborative domain is used, CQRS allows you to minimize merge conflicts at the domain level.
• When the Task-based interface is used in your application to guide the user through a complex process as a step or with a complex model, the write model has full-command processing on business logic and validation. The read model has no business logic and uses in the view model.
• When read data is tuned with the performance of write data and when several reads are greater than the number of writes.
• When one team can focus on a complex domain, which is part of the write model and other team focus on the reading model and user interface.
• When the system is required to evolve and contain multiple versions of the model, business rules change regularly.
• When the system is integrated with other systems like event sourcing, one system’s failure should not affect other systems.

This pattern is not recommended in the following scenario:

• When the domain and business rule of application is simple.
• When simple CRUD operation and data access operation are sufficient for your application.

Consider the following points when CQRS pattern used with Event-sourcing

• When systems based on this pattern are consistent and use separate read and write models.
• There will be a delay between event generation and event updating.
• The pattern adds complexity because code must be created to initiate and handle the event, update the view or object required by queries, or read model. When CQRS is used with events, sourcing requires a different approach to design the system. Event sourcing makes it easier to rebuild the view because it preserves changes.
• The materialized view is generating for a reading model or projection of data by replying event.

Also Read: Expert Advice from Rajiv Shah – Data Scientist and AI Researcher

Example

The following code shows the read model:

// Query interface
namespace ReadModel
{
  public interface StudentsDao
  {
    StudentDisplay FindById(int studentId);
    ICollection<StudentDisplay> FindByName(string name);
    ICollection<StudentDisplay> FindStudentResult(int studentId);
  }
  public class StudentDisplay
  {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email{ get; set; }
    public string RollNumber{ get; set; }
    public string Result{ get; set; }
  }
}

Following code shows the command handler:

public interface ICommand
{
  Guid Id { get; }
}
public class GenerateResult: ICommand
{
  public GenerateResult()
  {
    this.Id = Guid.NewGuid();
  }
  public Guid Id { get; set; }
  public int StudentId{ get; set; }
  public int Result{ get; set; }
}

Conclusion

In this blog, we have discussed the Command-Query Responsibility Segregation and problem without Command-Query Responsibility Segregation and the solution to those issues. We have also discussed a few benefits and Event sourcing with a simple example of the reading model and Command.