Development Approaches with Entity Framework

Entity Framework follows three different approaches while developing the application.

1. Database First
2. Code-First
4. Model-First

Database-First Approach

In the database-first development approach, we generate the context and entities for the existing database using the EDM wizard integrated with Visual Studio or executing the Entity Framework commands.

Entity Framework6 supports the database-first approach extensively.

Code-First Approach

We use this approach when we do not have an existing database for our application. In the Code-First approach, we start writing the entities and context class and then create the database from these classes using the migration command.

Developers who follow the Domain-Driven-Design principles, here we will prefer to begin with coding the domain classes first and then generate the database which is required to persist the data.

Model-First Approach

In Model-First Approach, we create entities, relationships, and the inheritance hierarchy.

Directly on the Visual Designer integrated with Visual Studio and then generated the entities, the context class, and the script of the database from the visual model.

EF6 includes limited support for this approach. Entity Framework Core does not support this approach.

Choosing the development approach for our application

We use the following flow chart to decide the right approach to develop the application using the Entity Framework.

The above figure shows that we already have an existing application with domain classes, then we can use the code-first approach because we can create a database from our existing classes. If we have an existing database, then we can create an EDM from an existing database in the database-first approach. If we do not have an existing database or domain classes, we will prefer to design the own DB model on the visual designer, and then we will go for the Model-First approach.

Persistence in Entity Framework

There are two scenarios when we are saving the entity to the database using the entity framework, and these are Connected Scenario, and Disconnected Scenario.

Connected Scenario

In the connected scenario, the same instance of the context class (derived from DBContext) is used for retrieving and saving the entities. The connected scenario keeps track of all the entities during its lifetime. This is useful in windows applications with the local database or database on the same network.

Here are the pros and cons of the Connected Scenario in Entity Framework.

Disconnected Scenario

In the disconnected scenario, different instances of the context are used to retrieve and save the entities in the database. The instance of the context is disposed of after retrieving the data, and a new instance is created to save the entities to the database.

The disconnected scenario is complex because an instance of the context doesn't track the entities, so we need to set an appropriate state to each entity before saving the entities using SaveChanges(). In the above figure, the application retrieves the entity graph using Context 1, and then the application performs some CUD (Create, Update, and Delete) operations using Context 2. Context 2 doesn't know which operation has been performed on the entity graph in this scenario.

This scenario is useful in Web applications or applications with a remote database.