There are different reasons to encourage developers to use Entity Framework (EF) Code First, the most important reasons to me are the ability to version control the database schema and the database migration feature which creates/updates the database schema from the code-base model.
Check this link for more information about the EF Code First.
If the migration feature is used, your application will check if the database has the latest schema – typically on app start up. The schema then might get updated to accommodate the new changes such as adding new table or fields to the database.
Assume that you’ve got a Sitecore multi-instance environment that uses a custom database managed by EF Code First, e.g. an error logging database. The custom database is accessible from every Sitecore instance in the environment. Also, assume that the environment is setups and you want to add a new field to the database to log extra information such as the machine name.
In entity framework, you’ve got two options to implement your migrations. Manual Migration or Automatic Migration; the former allows you to specify the migration steps and will give you the ability to customize the migration process as well. The latter works like magic, where EF automatically detects the schema changes and does the migration if needed. Both methods will store the migration information in the __MigrationHistory table.
Read More How to Achieve Zero-Downtime Sitecore Deployments (EF Automatic Migrations) – Part III