API Architecture (CQRS, Read-Only repository, ...)
I'll try to sketch the context as best as I can, I'll try and expand on this if needed.
We have an old WPF application (.NET Framework 4.6.1) that we wish to get rid of.
Before I started working on this project, it was already decided that it was going to use Blazor (WASM).
We have a seperate solution for our API, and a seperate solution for our FrontEnd - as well as a seperate project for the shared infra between the 2 (such as DTO's, enums, ...)
The implementation of our API should follow clean architecture as much as possible (being a junior, this sometimes feel very daunting, but I'll get there eventually).
The API is split into Modules, which each have their own Queries/Commands, Mappers (AutoMapper), Controllers, DbContext + repositories.
I've been taught by my company to use Read-Only DbContext/repositories where I can, but this confuses me right now in the following way:
DbContext
We created a ReadOnlyDbContext as follows that override all SaveChanges methods to throw an exception.
This also expostes the entity as IQueryable and AsNoTracking
Using this DbContext is fairly straightforward, if not for my question about repositories
Repositories
Now here's the interesting part...
We have a GenericRepository<TEntity, TKey> class, that implements a few basic operations.
Whenever we create a CQRS query, we ofcourse want to use a ReadOnly repository/context...
This confuses me however... this means I need to create both a 'read-write' and 'read-only' repository, but I can't really find any best practices involving this...
So I guess my question actually is... What're some best practices regarding repositories/DbContexts when creating a modular monolith where we want to use read-only where applicable?
Should we actually not bother using a read-only context/repo for modules that do some writing at some point? And only use read-only repo/context for modules that don't ever save anything?
1 Reply
Unknown User•8mo ago
Message Not Public
Sign In & Join Server To View