Explore the different approaches to model entities in Entity Framework

Entity Framework simplifies data access in your application by enabling you to write code to perform CRUD (Create, Read, Update and Delete) operations sans the need of interacting with the underlying database provider directly. There are three approaches to model your entities in Entity Framework: Code First, Model First, and Database First. This article discusses all these three approaches and their pros and cons.

What is the Entity Framework? Why all the hype?

Microsoft’s Entity Framework is an extended ORM that helps you isolate the object model of your application from the data model. It is an open source ORM framework for ADO.Net and is included as part of .Net Framework. In using ORM tools, you can focus on the business logic of the application and store data in the database with much less code. You can take advantage of an ORM to convert data between incompatible type systems — you can store your domain objects into the underlying database without having to worry about the internal intricacies on how the data is actually stored. The Entity Framework is a mature ORM from Microsoft and can be used with a wide variety of databases.

In the sections that follow, we will explore each of the three approaches to modeling entities using Entity Framework.

Code First

The Code First approach helps you to create the entities in your application by focusing on the domain requirements. In essence, you can follow Domain Driven Design (DDD) using this approach. Once your entities have been defined and the configurations specified, you can create the database on the fly using both. The Code First approach gives you more control over your code — you don’t need to work with autogenerated code anymore. I like this approach as this gives you a lot of flexibility and control. If you have the domain classes ready, I would always prefer this approach as you can easily create your database from the domain classes.

The downside to this approach is that any changes to the underlying database schema would be lost; in this approach your code defines and creates the database. The Code First approach allows you to use Entity Framework and define the entity model sans the designer or XML files. You can use the POCO (Plain Old CLR Objects) approach to define the model and generate your database.

In this approach you would typically create the entity classes. Here’s an example; a typical entity class is given below.

 public class Product

   {

      public int ProductId { get; set; }

      public string ProductName { get; set; }

      public float Price { get; set; }

   }

Next, you should define a custom data context by extending the DbContext class as shown below.

public class IDGContext : DbContext

   {

      public DbSet<Product> Products { get; set; }

   }

Lastly, you should specify the connection string in the configuration file. You are done!

Database First

You can use the Database First approach if the database is already designed and is ready. In this approach, the Entity Data Model (EDM) is created from the underlying database. As an example, you use the database first approach when you generate the edmx files in the Visual Studio IDE from the database. Manual changes to the database is possible easily and you can always update the EDM if need be (for example, if the schema of the underlying database changes). To do this, simply update the EDM from the database in the Visual Studio IDE.

Model First

In the Model First approach you can create the EDM first, then generate the database from it. You would typically create an empty EDM using the Entity Data Model Wizard in Visual Studio, define the entities and their relationships in Visual Studio, then generate the database from this defined model. You can easily create entities and define their relationships and associations in the designer in Visual Studio. You can also specify the Key property and the data types for the properties for your entities using the designer. You can use partial classes to implement additional features in your entities.

OK, but when should you use the Model First approach? Well, if neither the domain classes nor the database is ready and you would rather define the data model using a visual designer, this approach is for you. However, like in the Code First approach, in the Model First approach manual changes to the database would be lost as the model defines the database.