Over the past decade, CQRS has become more popular and implementing it with Entity Framework Core makes it easy. We’re going to start off by discussing what CQRS is, different ways to implement it, and why Entity Framework Core is ideally suited to it. We’ll finish with examples of command and query implementations.Continue reading “CQRS with Entity Framework Core”
For those who aren’t familiar, there is a concept in Domain Driven Design that distinguishes between objects with identity (entities) and those without (value objects). When we model the domain we typically think in terms of entities which are then persisted and modified over time. They form the basis for which we describe the business and interact with it, and often times, entities are the only objects developers create when modeling the system. Value objects provide a wealth of benefits though when applied appropriately.
Let me preface this blog post by saying that there are still times when a DTO makes sense. Also, this post is written from a .NET perspective, so some things may be different on your platform. What I want to address though is the tendency of many developers to just automatically create a set of DTOs for each layer for each domain model. As I mentioned in other blog posts, you should always think about why you are doing something before you are doing it. Continue reading “Think Before You Use The DTO Pattern”
That is, it’s dead if you are using Entity Framework Core. If you’re still using straight ADO.NET, or even just dapper, then the repository pattern still probably makes sense for you. If you’re using Entity Framework, then you really aren’t gaining much from doing so anymore. Five years ago, you could reasonably argue that it was beneficial to use the repository pattern, or some form of abstraction, over entity framework for the following reasons:
Continue reading “The Repository Pattern is Dead If You Use Entity Framework”