CQRS and dbContext

[raix]

Any thoughts / plans to provide a ReadWrite db context for Commands and a pure Read db context for Queries?
(Read would be optimized e.g. using replicas/named replicas, AsNoTracking, ApplicationIntent=ReadOnly etc.)

[tjementum]

Any thoughts / plans to provide a ReadWrite db context for Commands and a pure Read db context for Queries?
(Read would be optimized e.g. using replicas/named replicas, AsNoTracking, ApplicationIntent=ReadOnly etc.)

I think this is a concern for the Repository layer. A read-only or append-only repository can be enforced via an IRepository interface that excludes Add, Remove, or Update methods.

While we could create a dedicated DbContext with ApplicationIntent=ReadOnly, I believe this is overkill within a self-contained system, since it’s easy to gain write access anyway.

If you have performance problems, an alternative could be views, materialized views, or even stored procedures for read-only queries. If you use materialized views, there will be no locking issues on the main table, and scaling the database becomes straightforward.

Read replicas make the most sense for geo-replication, but that also introduces cross-region latency, consistency challenges, and data regulation concerns—not to mention the need for dedicated read-only services.

From my experience, SQL Server (especially the Hyperscale Tier) can handle massive workloads when used correctly, with a focus on optimizations like indexing, query tuning, etc.

Also, be mindful of how Entity Framework generates queries to avoid inefficient joins. I recommend avoiding navigational properties (like Customer.Orders) and Entity Framework’s .Include() method. Instead, perform multiple lookups and query based on primary keys—this helps scale much better by avoiding expensive joins.

PS: Everything is already AsNoTracking, so tracking is disabled by default.