Before going ahead, it would be useful to say a few words explaining what Code-First Migrations actually are and the advantages we gain by using them.
Whenever we’re developing an application and defining a Data Model, we can be sure that it will change a number of times for many good reasons: new requirements from the product owner, optimization processes, consolidation phases, and so on. A bunch of properties will be added, deleted, or have their type changed. Chances are, sooner or later, we’ll be adding new entities as well, and/or changing their relation pattern according to our ever-changing needs.
Each time we do something like that, we’ll also put our Data Model out of sync with its underlying, Code-First generated Database. This won’t be a problem when we’re debugging our app within a development environment, because that scenario usually allows us to recreate the Database from scratch whenever the project changes.
Upon deploying the application into production, we’ll be facing a whole different story; as long as we’re handling real data, dropping and recreating our Database won’t be an option anymore. This is what the Code-First Migrations feature is meant to address: giving the developer a chance to alter the Database schema without having to drop/recreate the whole thing.
We won’t dig more into this topic; Entity Framework Core is a world of its own, and addressing it in detail is out of the scope of this book. If you want to learn more, we suggest you start with the official EF Core MS documentation at https://docs.microsoft.com/en-us/ef/core/.