Clean Architecture
I'm trying to implement Clean Architecture in my web api, I'm also using the generic repository and unit of work pattern. I want to set my unit of work up as a singleton, but my Program.cs exists in my 'Presentation' (web) layer. This means it wants a reference to my Infrastructure layer (where my unit of work lives) which breaks clean architecture.
Can I and should I move Program.cs to a different layer? Any Suggestions
10 Replies
obligatory $vsa to solve all your "where should i put this" problems
https://www.youtube.com/watch?v=T-EwN9UqRwE
https://codeopinion.com/restructuring-to-a-vertical-slice-architecture/
dotnet
YouTube
Vertical Slice Architecture: How Does it Compare to Clean Architect...
Is Vertical Slice Architecture the next big thing or just as cool new kid?
Enterprise software development requires you to choose the right architecture. This session with Luke Parker will provide a realistic dive into Vertical Slice Architecture (VSA) with .NET; showcasing the potential shift from Clean Architecture (CA) to VSA.
You will lear...
Derek Comartin
CodeOpinion
Restructuring to a Vertical Slice Architecture
What is Vertical Slice Architecture? It's about focusing and organizing code by features and capabilities, not technical concerns!
What's your opinion on using unit or work pattern to abstract out entity framework. Is it useless abstraction?
yes, a dbcontext is already a unit of work (and dbsets are generic repositories, for that matter)
What if I didnt want a hard dependency on EF Core when testing?
The only reason you'd ever do this is to be able to change ORMs in the future
And to accomplish you'd be either
a) doing an imperial butt-ton of work
b) giving up 90% of EF's power
Your tests should use an actual database, not a mock
✅ Command successful. Added tag 'eftest'.
$eftest
https://learn.microsoft.com/en-us/ef/core/testing/testing-with-the-database
https://dotnet.testcontainers.org/
Testing against your Production Database System - EF Core
Techniques for testing EF Core applications against your production database system
is it really a hard dependency?
you still have the connector if you want to use different databases, mssql, mysql, etc