Mastering Entity Framework

Entity Framework relies on the conceptual data model for all its working. Let's try to understand what the Entity Data Model (EDM) is and how Entity Framework uses it to manage the database operations.

Before we start looking at the various options to create the EDM, let's talk about the development styles followed by the developers. Some organizations have separate teams working on the application and the database. In such cases, the database design is done first and then the application development starts. Another reason for doing the database design first is when the application being developed is a data centric application itself.

Instead, it might be possible that the application demands the creation of the conceptual domain models first. Then, based on these conceptual domain models, the database tables will be created, and the application will implement the business logic in terms of these conceptual business models.

Another possibility is that we are creating an application that is highly domain-centric, and the application contains the domain models implemented as classes. The database is needed only to persist these models with all the relations.

There are a range of different scenarios you might find yourself in—different approaches become appropriate according to the demands of your situation.

Entity Framework provides support for all these development styles and scenarios. We know that Entity Framework operates on the EDM, and lets us create this EDM in three ways in order to cater to the different development styles:

Before we start looking at these development styles in detail, let's try to do a comparative analysis of these styles. It will help us in understanding these styles in detail.

This approach has been available since the first version of Entity Framework. In this approach, we start with an already existing database and start creating our EDM from the existing database. Let's try to see how this works using the Entity Framework Database First approach with our ToDo sample. To use the Entity Framework Database First approach, we have to add a new ADO.NET EDM to our project:

Add a new ADO.NET EDM

Let's start by defining a database for the ToDo application. Let's create a simple table that will keep a track of all the ToDo items:

A table schema for the sample ToDo application

The application requirements state that it should be possible to perform the following activities on the ToDos:

When we add the EDM, it asks us whether we want to create the conceptual model from the existing database, or if we want to create an empty model. For the Database First approach, we need to select an existing database. The following screenshot shows the wizard step that asks you to select the database:

ADO.NET EDM wizard step 1—generate from the database

Once we choose to add the EDM, we need to specify the database that should be used to create it. So, the next step in the wizard will ask you for the connection to the database. Let's see what this wizard step looks like:

ADO.NET EDM wizard step 2—select the database

Once the connection is successfully established, the wizard shows us all the tables, views, procedures, and functions that we will want to access from our application. Using this wizard, we can also choose to include the foreign key relations in our conceptual model and singularization of the model name, in case the table name is plural in our conceptual model:

ADO.NET EDM wizard step 3—select the schema elements to be included in the EDM

Once the conceptual model is created, the EDM will be created for use in our application. The application will create a .EDMX file that contains all the information about our conceptual entity model and its mapping to the database tables:

Visual Entity Designer showing the default model

We can modify the conceptual model and change the mapping using entity designer. Let's try to change the property ToDo1 to ToDoItem in our conceptual model. Note that only the class property has been changed, and not the column name:

Visual Entity Designer showing the customized model

If we open the EDMX file, we can find the following three sections:

Once the EDM is created, we will get a class generated for each model object present in our conceptual model. We will also get the DBContext class that will let's use these strongly typed models:

Solution Explorer showing the generated DbContext and Model class

The generated DBContext class will look like this:

public partial class ToDoDBEntities : DbContext
{
    public ToDoDBEntities()
        : base("name=ToDoDBEntities")
    {
    }
    
    public virtual DbSet<ToDo> ToDos { get; set; }
}

The generated model class will look like this:

public partial class ToDo
{
    public int Id { get; set; }
    public string TodoItem { get; set; }
    public bool IsDone { get; set; }
}

Now we are ready to write typed queries against the generated conceptual model, and Entity Framework will execute our queries on the database, and return the results in the form of these strongly typed models. Creating new data or updating the existing data is also very easy, because Entity Framework automatically tracks the changes we make in our models, and lets us save the changes to the database. This can simply be done by calling the SaveChanges method on the DBContext class. One important thing to note here is that the read operation can utilize Language-Integrated Query (LINQ) to query the object data model, and Entity Framework will take care of converting it to the appropriate SQL query and retrieve the results.

If our application is a data-centric application, and all we need is to be able to perform CRUD operations using strongly typed objects, this is all that we are going to need. However, one of the great benefits of Entity Framework is being able to modify the conceptual models to better adapt to our domain needs, and then use the mappings to map the domain model to the database tables. We can have relationships between our domain models and still let them persist the data in a given set of tables.

In the later chapters, we will see how to manage multiple models, how we can define relationships between the entities, introduce inheritance hierarchies, customize entities, and much more. This will give you a good foundation to get started with the Entity Framework Database First approach if you haven't used it before, and will refresh your memory if you have.

The Model First approach is useful when we don't have a database to start with. Using this approach, we can create our models directly in the Visual Entity Designer, and then create the database schema based on our model. In this approach too, we can create entities and their properties, define relationships and constraints between the entities, and create inheritance relationships.

In this approach, we will first create the conceptual model, and based on this the database and the strongly typed objects will be created. To start with the Model First approach, we first need to add an ADO.NET EDM.

Let's try to add an ADO.NET EDM in our application:

Add a new ADO.NET EDM

Since we are planning to start with an empty model, we have to select an empty model in the wizard. The following screenshot shows the wizard step that asks you to select the option. We have to select Empty model in this step:

ADO.NET EDM wizard step 1—select the Model First approach

Once we choose the empty model, Entity Framework will show us the Visual Entity Designer. Now we can add the entities and relations to the designer area from the toolbar. The Entity Designer and the toolbar will look something like this:

An empty Visual Entity Designer after selecting the Model First approach

Let's try to add a new entity to our ToDo application and add properties to that model. Let's add a few properties to our ToDo model:

Adding a new property from Visual Entity Designer

Let's add the scalar properties needed for our ToDo model. Let's make the ID field a primary key field, a string property for ToDoItem, and a Boolean property for IsDone:

Visual Studio's Property panes showing the properties of a conceptual model

The created entity will look something like this:

The final model created from the Visual Entity Designer

Once we have the conceptual model created for our application, we have to create the database from this conceptual model. This can be done by right-clicking on the entity and choosing Generate Database from Model:

Generating database scripts from the Visual Entity Designer

This will prompt you to select the database connection. This wizard will not create the actual database, but it will generate the DDL for us, and we will have to use that DDL to create the database ourselves:

Wizard step to select the connection string to be used for a generated database script

After we select the database connection, the wizard will give us the SQL to create the database on the specified connection:

Wizard step showing the create database script

We can now copy this SQL and create the database. The Entity Framework has already created connectionString to use this connection, and wired up the DBContext class to perform the operations on this database. Let's take a look at the generated DbContext class:

public partial class ToDoModelContainer : DbContext
{
  public ToDoModelContainer()
    : base("name=ToDoModelContainer")
  {
  }

  public virtual DbSet<ToDo> ToDoes { get; set; }
}

The strongly typed objects will also be generated from the conceptual model. Let's take a look at our generated ToDo class:

public partial class ToDo
{
  public ToDo()
  {
    this.IsDone = false;
  }

  public int Id { get; set; }
  public string ToDoItem { get; set; }
  public bool IsDone { get; set; }
}

If we are using the Model First approach, one important thing to consider is that the incremental changes in our model will not perform the incremental updates to the database. Rather, it will give us the SQL to create the updated database from the ground up.

Now, let's take a look at the Entity Framework Code First approach. In this approach, we will start by creating the model classes ourselves. We will then implement our business logic against these classes, and then if we need to persist these models, we can use the Entity Framework Code First framework to save these models to the database. Thus, the Entity Framework Code First approach enables us to write simple C# classes, that is, Plain Old CLR Objects (POCOs) for our models, and then lets us persist them in a data store by defining a DbContext class for our model classes.

So, if we want to implement our ToDo application using the Code First approach, we will first have to create the ToDo model ourselves. Let's create a simple ToDo class that will keep track of our ToDo items:

public class ToDo
{
    public int Id { get; set; }
    public string ToDoItem { get; set; }
    public bool IsDone { get; set; }
}

Once we have the ToDo class ready, we need to start thinking about how the database will be created from our classes. We need to tell Entity Framework how to use our classes and generate the database accordingly. We want to tell the database generation module about all the persistence information, such as table names, key columns, and so on. We can do this in our model classes. So, if we try to put these attributes in our model class, our resultant ToDo model will look like this:

[Table("ToDo")] // Table name
public class ToDo
{
  [Key] // Primary key
      public int Id { get; set; }

  [Column("ToDoItem", TypeName="ntext")]
      public string ToDoItem { get; set; }

  [Column("IsDone", TypeName="bit")]
      public bool IsDone { get; set; }
}

In the preceding code, we updated our class with a table attribute passing in the table name. This will tell the Entity Framework that a table should be created for this class. Each property of the class can be updated with the Column attribute, and we can specify the name of the column this property should be mapped to and the data type. The Key attribute will be used to specify the property that should be used as a primary key.

Entity Framework uses the DBContext class to save the models to the database. In the Code First approach, we need to create the DBContext class ourselves too. Let's see how we can implement our DBContext class:

public partial class ToDoDBContext : DbContext
{
    public ToDoDBContext()
        : base("name=ToDoConnectionString")
    {
    }
    
    public DbSet<ToDo> ToDoes { get; set; }
}

The context class that we are creating should be derived from the DbContext class. The context class will also keep DbSet of ToDos that will represent the list of ToDo items being retrieved from the table. The constructor of the context class will pass the name of connectionString to the base DbContext class. This connectionString will be used to connect to the database.

Another possibility is to keep the name of the connectionString the same as the DbContext class name. The Entity Framework will be able to use the corresponding DbContext class with this connectionString to persist the data. This is an example of the Convention over configurations principle. However, this is also flexible, so that we have the possibility of giving custom names to the connectionStrings.

Now to be able to use Entity Framework to persist the data, we just need to create this connectionString in the XML configuration, and Entity Framework will take care of creating the database and performing the CRUD operations on their respective models.

This has shown you how to use the Code First approach using a single model. In later chapters, you will see how to use multiple models and have relationships between them, how we can define complex types, and customize models as per our application requirements.

We have looked at how Entity Framework supports various development approaches and lets us create the conceptual model and data access logic very easily. We have seen that Entity Framework depends on the EDM to perform the database CRUD operations, and we have also looked at the various ways to create the conceptual model and map it to the database using the Database First, Model First, and Code First approaches.

To fully understand the benefits of Entity Framework over ADO.NET, we must also look at how easy and efficient it is to use Entity Framework to perform the actual operations. This will also show how performing CRUD operations is the same, irrespective of the approach we take. Let's now see how we can perform CRUD operations using Entity Framework to fully understand the benefits of Entity Framework.

We will perform CRUD operations on our ToDo model using the Entity Framework DbContext class.

Now let's say we have a model for our ToDo item, that is, ToDo. We also have the DbContext class created to perform CRUD operations on the ToDo model. Let's take a look at how we can use Entity Framework to perform CRUD operations on our ToDo model. The important thing to note in these examples would be the use of LINQ. We will write all our queries in LINQ, and Entity Framework will take care of converting it to the appropriate SQL and return the results.

using(ToDoDBEntities db = new ToDoDBEntities())
{
    IEnumerable<ToDo> todoItems = db.ToDos;
}

using (ToDoDBEntities db = new ToDoDBEntities())
{
  ToDo todo1 = db.ToDos.Find(id);

  ToDo todo3 = db.ToDos.FirstOrDefault(item => item.TodoItem == "Test item");
  ToDo todo2 = db.ToDos.SingleOrDefault(item => item.TodoItem == "Test item");    
  

}

using (ToDoDBEntities db = new ToDoDBEntities())
{
    ToDo todoItem = new ToDo();
    todoItem.TodoItem = "This is a test item.";
    todoItem.IsDone = false;
     db.ToDos.Add(todoItem);

    db.SaveChanges();
}

using (ToDoDBEntities db = new ToDoDBEntities())
{
    int id = 3;
    ToDo todo = db.ToDos.Find(id);

    todo.TodoItem = "This has been updated";
    todo.IsDone = false;
    db.SaveChanges();
}

using (ToDoDBEntities db = new ToDoDBEntities())
{
  db.Entry(todo).State = EntityState.Modified;
  db.SaveChanges();
}

using (ToDoDBEntities db = new ToDoDBEntities())
{
    int id = 3;
   ToDo todo = db.ToDos.Find(id);
    db.ToDos.Remove(todo);
    db.SaveChanges();
}

Now, we saw the three options to create the EDM and the DbContext class. Which approach should be used in which scenario, is often a question that many developers ask. There is no definite reason for choosing any particular approach, but here is a small checklist that the developers might find very useful while deciding on which approach to choose. If at any point, the answer to any question is yes, then that approach should be used without even looking at the next question in the checklist:

In this chapter, we talked about the ORMs and how ORMs can ease the task of writing data access code. We saw what Entity Framework is and how it works. We then saw the various approaches for using Entity Framework. We performed CRUD operations on a simple model to see Entity Framework in action. Finally, we looked at which approach would better fit our needs based on the given scenario.

In the next chapter, we will see how we can use the Entity Framework Database First approach to model complex relationships between database tables as relationships between the domain models. We will also see how to work with these related models using Entity Framework.