CQRS and MediatR In ASP.NET Core
32 هزار بار بازدید -
2 سال پیش
-
►► Master Web API development
►► Master Web API development Best Practices: https://bit.ly/3TnqoFQ
►► Build great web apps in Blazor WebAssembly: https://bit.ly/437g87T
►► Support us on Patreon and get the source code: Patreon: CodeMaze
There were some changes in the newest version of MediatR, so we strongly recommend watching our new video using the latest library version and the latest .NET framework:
►► CQRS And Mediatr in ASP.NET Core - CQRS And MediatR in ASP.NET Core - I...
DESCRIPTION:
In this video, we are going to provide a brief introduction to the CQRS pattern, and how the .NET library MediatR helps us build software with this architecture.
0:00 Introduction
4:19 MediatR Implementation
11:58 Requests With MediatR
16:29 MediatR Commands
27:58 MediatR Notifications
34:30 MediatR Behaviors
LINKS MENTIONED IN THE VIDEO:
►► Handling GET requests: Handling GET requests with ASP.NET Co...
►► Handling POST, PUT, and DELETE Requests: Handling POST, PUT and DELETE Request...
FOLLOW US ON SOCIAL MEDIA!
►► LinkedIn: marinko-spasojevic
►► Twitter: CodeMazeBlog
►► Facebook: CodeMazeBlog
VIDEO SUMMARY:
CQRS and the Mediator Pattern
The MediatR library was built to facilitate two primary software architecture patterns: CQRS and the Mediator pattern. Whilst similar, let’s spend a moment understanding the principles behind each pattern.
CQRS.
CQRS stands for “Command Query Responsibility Segregation”. As the acronym suggests, it’s all about splitting the responsibility of commands and queries into different models.
If we think about the commonly used Create-Read-Update-Delete pattern, usually we have the user interface interacting with a datastore responsible for all four operations. CQRS would instead have us split these operations into two models, one for the queries - read operations, and another for the commands - create update and delete operations.
The CQRS pattern makes no formal requirements of how this separation occurs. It could be as simple as a separate class in the same application, all the way up to separate physical applications on different servers. That decision would be based on factors such as scaling requirements and infrastructure, so we won’t go into that decision path today.
The key point is that to create a CQRS system, we just need to split the reads from the writes.
So, what problems do we solve with it?
Well, when we design a system, we start with data storage. We perform database normalization, add primary and foreign keys to enforce referential integrity, add indexes, and generally ensure the “write system” is optimized. This is a common setup for a relational database such as SQL Server or MySQL. Other times, we think about the read use cases first, then try and add that into a database, worrying less about duplication or other relational DB concerns.
Neither approach is wrong. But the issue is that it’s a constant balancing act between reads and writes, and eventually, one side will “win out”. All further development means both sides need to be analyzed and often one is compromised.
CQRS allows us to “break free” from these considerations, and give each system the equal design and consideration it deserves, without worrying about the impact of the other system. This has tremendous benefits on both performance and agility, especially if separate teams are working on these systems.
Mediator Pattern
After CQRS, let’s talk a bit about the Mediator pattern.
The Mediator pattern is simply defining an object that encapsulates how objects interact with each other. Instead of having two or more objects take a direct dependency on each other, they instead interact with a “mediator”, who is in charge of sending those interactions to the other party.
We can see that SomeService sends a message to the Mediator, and the Mediator then invokes multiple services to handle the message. There is no direct dependency between any of the blue components.
The reason the Mediator pattern is useful is the same reason a pattern like Inversion of Control is useful. It enables “loose coupling”, as the dependency graph is minimized and therefore code is simpler and easier to test. In other words, the fewer considerations a component has, the easier it is to develop and evolve.
Now that we’ve been over some theory, let’s talk about how the MediatR package makes all these things possible.
►► Build great web apps in Blazor WebAssembly: https://bit.ly/437g87T
►► Support us on Patreon and get the source code: Patreon: CodeMaze
There were some changes in the newest version of MediatR, so we strongly recommend watching our new video using the latest library version and the latest .NET framework:
►► CQRS And Mediatr in ASP.NET Core - CQRS And MediatR in ASP.NET Core - I...
DESCRIPTION:
In this video, we are going to provide a brief introduction to the CQRS pattern, and how the .NET library MediatR helps us build software with this architecture.
0:00 Introduction
4:19 MediatR Implementation
11:58 Requests With MediatR
16:29 MediatR Commands
27:58 MediatR Notifications
34:30 MediatR Behaviors
LINKS MENTIONED IN THE VIDEO:
►► Handling GET requests: Handling GET requests with ASP.NET Co...
►► Handling POST, PUT, and DELETE Requests: Handling POST, PUT and DELETE Request...
FOLLOW US ON SOCIAL MEDIA!
►► LinkedIn: marinko-spasojevic
►► Twitter: CodeMazeBlog
►► Facebook: CodeMazeBlog
VIDEO SUMMARY:
CQRS and the Mediator Pattern
The MediatR library was built to facilitate two primary software architecture patterns: CQRS and the Mediator pattern. Whilst similar, let’s spend a moment understanding the principles behind each pattern.
CQRS.
CQRS stands for “Command Query Responsibility Segregation”. As the acronym suggests, it’s all about splitting the responsibility of commands and queries into different models.
If we think about the commonly used Create-Read-Update-Delete pattern, usually we have the user interface interacting with a datastore responsible for all four operations. CQRS would instead have us split these operations into two models, one for the queries - read operations, and another for the commands - create update and delete operations.
The CQRS pattern makes no formal requirements of how this separation occurs. It could be as simple as a separate class in the same application, all the way up to separate physical applications on different servers. That decision would be based on factors such as scaling requirements and infrastructure, so we won’t go into that decision path today.
The key point is that to create a CQRS system, we just need to split the reads from the writes.
So, what problems do we solve with it?
Well, when we design a system, we start with data storage. We perform database normalization, add primary and foreign keys to enforce referential integrity, add indexes, and generally ensure the “write system” is optimized. This is a common setup for a relational database such as SQL Server or MySQL. Other times, we think about the read use cases first, then try and add that into a database, worrying less about duplication or other relational DB concerns.
Neither approach is wrong. But the issue is that it’s a constant balancing act between reads and writes, and eventually, one side will “win out”. All further development means both sides need to be analyzed and often one is compromised.
CQRS allows us to “break free” from these considerations, and give each system the equal design and consideration it deserves, without worrying about the impact of the other system. This has tremendous benefits on both performance and agility, especially if separate teams are working on these systems.
Mediator Pattern
After CQRS, let’s talk a bit about the Mediator pattern.
The Mediator pattern is simply defining an object that encapsulates how objects interact with each other. Instead of having two or more objects take a direct dependency on each other, they instead interact with a “mediator”, who is in charge of sending those interactions to the other party.
We can see that SomeService sends a message to the Mediator, and the Mediator then invokes multiple services to handle the message. There is no direct dependency between any of the blue components.
The reason the Mediator pattern is useful is the same reason a pattern like Inversion of Control is useful. It enables “loose coupling”, as the dependency graph is minimized and therefore code is simpler and easier to test. In other words, the fewer considerations a component has, the easier it is to develop and evolve.
Now that we’ve been over some theory, let’s talk about how the MediatR package makes all these things possible.
2 سال پیش
در تاریخ 1401/03/12 منتشر شده
است.
32,095
بـار بازدید شده