stevon8ter
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?
26 replies
❔ Which ORM? [query sys.objects, ...]
Hey guys
So I already have some decent experience using EF as ORM to create some applications at work.
However... I'm about to start working on 1 of my hobby-projects, and I'd really appreciate some help in deciding which ORM to use.
Some context about the project, which might help in getting good advice:
The project would have its own Database (Master), which would store certain information about another Database (Client) - The question is mainly focused around the Client DB.
Let's also assume I wouldn't want to add any tables/views to the Client DB.
In order to store (useful) information about the Client, I'd like to query its sys.xxx tables
Now the real question... Is there any ORM I could use to query those tables, or should I be looking at writing raw SQL (either using an ORM or not).
Any advice (or feedback on why this is a bad idea?) would be greatly appreciated.
Thanks in advance
Kind regards
Steven
14 replies
