Gilles TOURREAU
Migration issues -EF core.
The MS documentation is enough:
For example, read this page : https://learn.microsoft.com/en-us/ef/core/modeling/constructors and this one https://learn.microsoft.com/en-us/ef/core/modeling/relationships/navigations, you will see the limitation of navigation property.
If you want to do a real domain implementation, I advice you to create :
- Your domain with entities as you really want (with OO style, constructor, value objects,...).
- Create entities for EF which will be used only to query / persist your entity of the domain. You can use manual mapping between the model and EF Entity or a mapper like auto mapper.
We use this approach in my project, because:
- I want to use a real domain that reflect our business rules / entities.
- I don't want that developers deform our domain, because EF have limitations of the design for the entities. We use only EF entities to persist data and query using Linq.
With this approach, of course you will have the fellling to copy/paste entities of your domain to create EF entities.
But with this approach, you can make your domain entities independant of the structure of the SQL tables that you want to query/persist. Specially, it is very interesting when you have complex n-n relationship in your domain and you want to persist it differently in your database (with a JSON column for example,...).
In my projects, my teams make the EF entities as internal and are limited to the infrastructure/persistance layers and we suffix it with the
Db name to avoid conflict with the domain entities and EF entities class names when doing the mapping.
And last thing, when doing this approach, it is easy to perform unit tests for our domain and our repositories separately.15 replies