There are two popular Microsoft Technologies used for database migrations that are often considered mutually exclusive. You can use Entity Framework by designing your application code first, and have it create database migrations for your database. You can also use a Database project, and have it generate your database migrations through a database comparison, or even code comparison. These two techniques are often used exclusively for a project.
Since the Database Project technique can be used through comparison, it is possible to do both. Here’s what you can do.
If you use a local database for your application development, you can manage it using Entity Framework through code first. In this fashion, you can be assured that your database structure, at least through application development, follows along in lock step with your Entity Framework design of your application. That is the biggest advantage of code first database development in the first place.
However, your DBA insists on using a database project. They find value in the management of the database objects outside of code. So, how do you get the changes you handled from code first into your database?
The database project has the ability to be modified through comparison to a database. As a result, you can create your database modifications in your database project by comparing it to your local database. In this fashion, you can use both techniques, but not have to write two sets of code for your database design. Your DBA can now use migrations from either the Database Project, or the Entity Framework migrations. They have a choice as do you.
So, now when your DBA or Architect insists on using a database project for handling database migrations, you don’t have to lose the advantages you prefer as a developer from using code first in Entity Framework.
Cheers,
Ben