The article provides a quick guide to understanding Entity Framework.
Why Entity Framework?
Entity Framework is an ORM layer which implements the Unit of Work pattern. For ASP.NET, the request processing can be considered as a business transaction. Entity framework keeps a track of all changes made to database entities and allows the changes to be saved in a single transaction.
DbContext is the class that keep track of the entities. DbSet<T> represents an entity collection. DbSet<T> has Add and Remove methods. DbSet can be queried using LINQ statements. DbContext has SaveChanges method which allows multiple updates to be batched in a single transaction.
Flavours of Entity Framework
Entity Framework has three flavours: Database first, Model first, Code first. Database first and Code first is self-explanatory but what is model first? Entity Framework has a Model which is represented by XML called EDMX. The model describes the database and the classes as well as stores the mapping between them.
Representing the model is the fundamental work involved in Entity Framework. There are some conventions which allow an implicit model to be generated. For example, the table names can match the class names, and the column names can match the property names.
Entity Framework Code First
Entity Framework Code First is my preferred way of working. In this approach, the entity classes are written in plain C# code (vs auto-generated). The real work involves mapping of the C# code with database tables and columns. There are two approaches that can be taken: Data Annotations or Fluent code mapping. Please refer to Entity Framework Tutorials for more information. Some of the mappings include setting table name, setting column name, setting primary key, setting foreign key, setting identity column, etc.
Automatic or Manual Migrations
When DbContext is first called, it makes use of a database initializer. The default initializer creates a new database, if no database exists. It also creates a __MigrationHistory table. The Migration history table stores the entire Model as EDMX in the Model column.
Everytime, DbContext is first called, Entity Framework retrieves the Model from __MigrationHistory. If there is a discrepancy between the current model and the model stored in __MigrationHistory, an exception is thrown. Entity Framework prompts for a migration. There are two types of migration: Automatic Migration or Manual Migration.
I prefer automatic migration. Automatic migration will work as long as the differential script is permissable (no dropping tables). The update-database command in NuGet package console allows any database to be updated with the current model.
Automatic migration can be made to work for complex schema updates (which involve dropping tables). To allow complex schema updates (in early phases of development), there are other database initializers available which drops and recreates the database. All built-in initializer have a Seed method which allow master data to be recreated if database is dropped. It is also possible to create a custom initializer (null initializer) which is useful for production deployments.
Apart from database initializers, there are Migration Configurators that allow seeding data after migrations. This allows update-database to call only seed code when there are no model changes.
Automatic migrations are useful for syncing multiple databases across environments and seeding them with master data. For production database, some custom code is required.