You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been bouncing back and forth between this and Steve Smith's (ardalis) sample Clean Architecture projects trying to understand how to better organize my code for maintainability, testing, etc. These are fantastic resources that clearly took an enormous amount of time to curate.
One thing I keep running into is, how do you decide where to draw the line for what qualifies as Infrastructure?
In this project, the decision was made not to abstract Ef-Core completely away, and instead introduce a dependency on Microsoft.EntityFrameworkCore in the Application layer and create a thin interface for IApplicationDbContext so you have direct access to the DbSets. In the Ardalis example, they go a step further and abstract Ef-Core away entirely by introducing Repository Interfaces and Specifications in the Core (Shared.Kernel) layer.
When I moved on to Validation I noticed that this project uses FluentValidation directly in the Application layer instead of creating interfaces in Core and abstracting the concrete implementation away to Infrastructure.
In every sample project I have looked at, it feels like everyone thinks the DAL is an ugly stepchild that needs to be hidden away so it can be swapped out and unit tested. But then you'll find all kinds of other hard dependencies on libraries like FluentValidation, Mediatr, AutoMapper, MailKit, etc. How do you decide where to draw the line?
For instance... In my next application, I need to display a table of transaction details that include properties from the User that created the transaction (name, email, etc). User is part of Identity which is buried in Infrastructure. I can introduce a UserId property on the transactions in the domain, but with the User in the Infrastructure layer, I cannot create a navigation property. Without a navigation property querying becomes the dreaded 1 + N performance sinkhole. I've already cheated and make the Application dependent on Microsoft.EntityFramework like this project. It would certainly be easier to make my Domain project depend on Microsoft.AspNetCore.Identity.EntityFrameworkCore so I could create navigation properties to the Identity users.
Curious to see what your thoughts are and how folks handle these things in the real world!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've been bouncing back and forth between this and Steve Smith's (ardalis) sample Clean Architecture projects trying to understand how to better organize my code for maintainability, testing, etc. These are fantastic resources that clearly took an enormous amount of time to curate.
One thing I keep running into is, how do you decide where to draw the line for what qualifies as Infrastructure?
In this project, the decision was made not to abstract Ef-Core completely away, and instead introduce a dependency on Microsoft.EntityFrameworkCore in the Application layer and create a thin interface for IApplicationDbContext so you have direct access to the DbSets. In the Ardalis example, they go a step further and abstract Ef-Core away entirely by introducing Repository Interfaces and Specifications in the Core (Shared.Kernel) layer.
When I moved on to Validation I noticed that this project uses FluentValidation directly in the Application layer instead of creating interfaces in Core and abstracting the concrete implementation away to Infrastructure.
In every sample project I have looked at, it feels like everyone thinks the DAL is an ugly stepchild that needs to be hidden away so it can be swapped out and unit tested. But then you'll find all kinds of other hard dependencies on libraries like FluentValidation, Mediatr, AutoMapper, MailKit, etc. How do you decide where to draw the line?
For instance... In my next application, I need to display a table of transaction details that include properties from the User that created the transaction (name, email, etc). User is part of Identity which is buried in Infrastructure. I can introduce a UserId property on the transactions in the domain, but with the User in the Infrastructure layer, I cannot create a navigation property. Without a navigation property querying becomes the dreaded 1 + N performance sinkhole. I've already cheated and make the Application dependent on Microsoft.EntityFramework like this project. It would certainly be easier to make my Domain project depend on Microsoft.AspNetCore.Identity.EntityFrameworkCore so I could create navigation properties to the Identity users.
Curious to see what your thoughts are and how folks handle these things in the real world!
Beta Was this translation helpful? Give feedback.
All reactions