EF architecture ~ CodeFirst from initialization to database migration, efcodefirst
Introduction
CodeFirst is a development mode of EntityFrameworks, that is, code first. It mainly uses Business Code to generate databases through code, and adds the powerful data table comparison function of migration to generate database versions, this allows program developers to directly maintain migration without maintaining database changes. It contains all change records for the current version and previous versions!
Migration articles written by Uncle
60th back to EF architecture ~ Migrations of CodeFirst production environment
62nd back to EF architecture ~ Execution sequence of Migration data Migration
Start today's "step-by-step learning of Migration database version control"
(1) EF-CodeFirst helps us establish a database and initialize a data table.
The first time you create a data model, run the program, automatically create databases and data tables, and perform Initialization
Data Model
Data Initialization
Registration of EF in LindAgile
When a database is created for the first time, the name of the data table can be controlled in the singular and plural forms.
Protected override void OnModelCreating (DbModelBuilder modelBuilder) {// note that when the form is in the plural form, the entity cannot be underlined and must be the word modelBuilder. conventions. remove <System. data. entity. modelConfiguration. conventions. pluralizingTableNameConvention> ();
}
Among them, the _ MigrationHistory table is a data table for Data Change, reflecting the database history.
(2) Start data migration
At this time, we can see that there is no migrations folder in the solution, because you have not enabled the change plan.
This folder appears only when the change is enabled.
Enable-Migrations
The migrations folder is displayed in the project, which stores the change records of our database.
If we add a new data entity DO, or modify the original entity, and want to upgrade a change record, we can use add-migration to change the name)
Then there will be one more change file in the Migrations directory of our project, which starts with a timestamp. When we execute a change, this timestamp is the key to its sequential execution.
(3) Update the model change to the database
At the same time, let's look at a data table _ MigrationHistory, which has not changed because we have not updated the change to the database. If you want to update it to the database, you can use update-database to implement it, if no version number is added, the latest change record is updated by default. It will include the previous change code. During the update, it will be compared with the change record in the _ MigrationHistory table, if the version has been updated, it will not be executed, but will only be updated backward!
After the execution is complete, let's take a look at the changes to the data table. It will also have a new change record. We will use this method to change the data table later, EF-migration as long as we make good use of it, it will only make our development faster!
(4) change the model to an SQL script for use in the production environment
Update-Database -Script -SourceMigration: $InitialDatabase -TargetMigration:init
After the above code is executed, an SQL file is generated. We can execute this file in the production environment, and the database is updated!
I hope this article will help you!