When and How To Apply CQRS in an ASP.NET Core Application With EF Core

Check out Dometrain and use code ZORAN for 15% off any course ► dometrain.com/?coupon_code=ZORAN
Become a sponsor to access source code ► / zoranhorvat
Join Discord server with topics on C# ► codinghelmet.com/go/discord
Enroll course Beginning Object-Oriented Programming with C# ► codinghelmet.com/go/beginning...
Subscribe ► / @zoran-horvat
When the code that operates on storage becomes too complex due to mixed responsibilities regarding updates, validation, processes, and plain queries, we look for CQRS. This design principle states that we should segregate commands from queries and solve each using its own tools and design methods.
Despite what some programmers believe, CQRS does not require separate databases for commands and queries. It only requires separate models for commands and queries, and that is all you need to get going.
Once you understand that writing data requires one set of rules and models, whereas querying, often in many different shapes, requires an entirely different set of models, you can apply CQRS.
This video demonstrates how easy it is to introduce CQRS to an ASP.NET Core application with Entity Framework Core.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️COPYRIGHT NOTICE:
The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.
#csharp #dotnet #objectorientedprogramming

[@zoran-horvat]

Check out Dometrain and use code ZORAN for 15% off any course ► dometrain.com/?coupon_code=ZORAN

[@johnnaysmith7218]

Good explanation. I've used CQRS within one detabase for a while. Didn't even know that it is usually used for more then one database...

[@seangwright]

I like using CQRS on all types of projects. Not because it helps me scale a solution, but because it's a good mental model for operations in a system and helps me keep a system organized, making it more comprehensible for others.

[@zoran-horvat]

That is my motivation as well. The types of projects I work on do not require a full-blown implementation of CQRS, and still I apply its striped-down variant all the time.

[@johnnaysmith7218]

Me too. Also, especially in API's I like to keep my calls simple, by calling C/Q directly in endpoint and keeping calls to a repo's methods, message queue or something else in a handler of a C/Q. That way my controllers remains clear.

[@metallixbrother]

Thanks for another great video. You mentioned the possibility of separating domain and persistence model. Whilst I imagine that this would be relatively simple for queries (I believe that this would introduce another level of mapping), what would be the recommendation for commands, given that our domain models presumably lack tracking that EF Core provides?

[@zoran-horvat]

That is a very difficult question. You are right that the separation affects command. Queries already bring their own mapping, which is easy to introduce because the mapping is one-way. There are several methods of implementing separate models. The funniest idea I know of is to make the domain model observable, i.e. to implement the Observer pattern. The persistence layer would subscribe to updates and apply them to the database (or the DbContext). I am thinking of making a video with that idea.

[@alfonsdeda8912]

Hi Zoran, great video! Is good to use dbcontext directly in presentation layer, shouldn't I instead do a service/repository layer with all my queries and commands with cqrs in another layer and use dtos?

[@zoran-horvat]

If my custom DbContext implemented a custom interface with all methods defined as they are now, would that change anything? Vertical coupling within one feature is not such an issue, especially if it reduces the code size. I see much greater danger in horizontal coupling, such as my page displaying books also accessing prices - that is another component's responsibility. In the final version of the demo, the prices are obtained from an interface indeed, the implementation of which holds that same DbContext again, but who cares.

[@alfonsdeda8912]

My idea of separation was only to not use the dbcontext directly in razor page but instead use an interface, because in future maybe I won't use ef core but for example dapper and this would loose couple the page from the data manager, is this a wrong approach?

[@zoran-horvat]

@@alfonsdeda8912 Did you ever substitute one database provider with another in a component? Are you aware that repositories, transactions and a few other details are tightly bound to every provider to such a degree that you would have to change all the operations that update the database if you just switched the implementation? The difference between EF and Dapper is so great that there is no common interface that both can satisfy. Conversely, if you insisted on a common interface, that interface would remove what EF does best - any abstraction can only be as powerful as the worst of its implementers! All that only underlines my previous conclusion that vertical coupling is not a big deal. Many evangelists and authors will teach you that it is, putting an entirely needless burden of achieving 100% of persistence ignorance in your code. But what they don't tell you is that all you will have when you go to sleep is hands full of tired fingers and nothing more. The things that hurt your design lie elsewhere.

[@alfonsdeda8912]

@@zoran-horvat Thank you very much for your response, I should only inject a service interface with getBooks and other methods that the page needs, and in service implementation I would use ef core or other db providers if this changes, but maybe I misunderstood the sense of the video. Thank you very much for your time.