There were some problems when generating a database schema from business objects with EF Core:
- No support for structural properties
- No support for interface properties
- I need additional columns, which should only belong to the data level.
I do not want to change my layer of business (structures / interfaces to classes) just because of EF, because that violates the principles of clean architecture (framework should serve your application, not vice versa). Adding persistence-specific columns to the business layer is also out of the question.
I suppose the right thing is to add persistence objects to the persistence layer that would represent entities in the business layer.
In addition, some of the business layer's mappers would need to be used to abstract persistence objects that they map to the business entities.
Some questions about this approach:
- Is that correct? Are there alternatives? For example, EF configuration functions that allow me to solve the problems listed above without replicating entities in the persistence layer?
- This feels like a lot of boilerplate code and the replication of the same features. Seems like this code could be generated automatically by a tool. Is there something like that?
- Is there a good example of what such an approach should look like?