Document keeping EF Core models In sync when changing both the model and the database (Hybrid approach)

[oluatte]

We are trying to use EF Core - Database First. We understand the advantages of code first but have compliance requirements that make database first right for us. We have many questions, requests:

Keeping EF Core In Sync
What does it mean exactly to keep the EF Core model in sync with the database? What parts of the Fluent API or attributes are for "migrations" and what parts are for "synchronization"? Do constraint name have to match? Does Delete behavior matter? Indexes? Where is the actual line between the migration feature that is bundled (no pun intended) with EF Core and the core ORM?

Validating Sync Status
Assuming we figure out the above question and are willing and able to do all the work of keeping things in sync. It should be possible to validate via integration tests that an EF Core model matches a database...at least for the ORM feature.

Documentation
Please, please add more documentation about Database First. It should be a well documented option.

API
Please make it easy to use the ORM parts of EF Core without running into migrations. The API surface area (fluent or otherwise) should make clear what features are for migrations and what features are for the ORM.

"Sync Validation"
Please add APIs to validate whether or not an EF Core model is in sync with a database.

Documentation
Please document the database first approach properly. Tradeoffs, effort required, limitations etc. Please document what is required to keep an EF Core model in sync.

EF Core is a very nice ORM and the migration feature is great as well. Please don't make it an all or nothing proposition.

[ErikEJ]

Have a look at EF Core Power Tools docs and demo videos

[ajcvickers]

Keeping EF Core In Sync

This is something we should document better. It's also related to dotnet/efcore#10890, which is about leaving out everything not needed by the runtime when scaffolding from an existing database. The items listed there are basically the things not needed, but, as I said, we should document this better.

Validating Sync Status

Generally, writing integration tests that use the new database structures should cover this. It's also very common to scaffold the the context and types again when the database changes. As @ErikEJ said, his docs are a good source of information on this.

Documentation

Agreed.

[oluatte]

Thanks for the super quick response, really appreciate it.

Have a look at EF Core Power Tools docs and demo videos

Thanks @ErikEJ. I have been checked out EF Core Power Tools, it's great although I am not sure it quite fits our scenario.

We aren't actually scaffolding our models from the database. Our core models are DDD style and we map to the database using type configurations. We would like to:

1. Make a database change
2. Update the right DDD model
3. Update the type mapping between them.

Generally, writing integration tests that use the new database structures should cover this.

This is can be a significant burden for a large db / model with complex arrangements. It forces us to apply integration tests everywhere instead of where we get the most bang for buck (given that integration tests are harder to manager than unit tests). Would love for something to validate this at a general level.