Earlier quoted context omitted.
I'm curious, why would this be bad? I've generally always seen it as best practice to create classes in your domain model and try to write your ideal code and then have separate classes/DTOs that are used for communicating outside your domain model such as reading/writing to a database using an ORM or responding from an API with your ideal model for the consumer (since more often than not consumers don't need or want…
Abstractions are useful to make a box and put horrors of edge case handling or business requirements variability in it :) But if there are little of those, no need to make them prematurely. Field mapping is something for EF Core mapper configuration or repository implementation to worry about, no need to do the job twice. You often don't need separate "Host" and "Core" projects either. And if you ever need to migrate…
Yeah mate, let's create a generic repository over the top of EF's perfectly decent DbSet, just in case we ever decide to switch ORMs!