1. Introduction

Introduction

Most software we create uses data and we have to store the data in for example SQL Server, Oracle, MySQL databases. Afterwards we retrieve it back to our application, let users modify it,or create new data and persist it back into our database. For decades we spent a lot of time writing code just to get data in and out of our database.  Instead of writing such code we can make use of Entity Framework which is a framework for accessing data, and we call it an Object Relational Mapper or ORM.


Object Relational Mapper (ORM)

Entity Framework is an Object Relational Mapper (ORM). An ORM simplifies the effort that we have to make when we’re going from objects in our software to relational data that’s persisted in a database. The tasks that the ORM will take care of for us are creating connections,  commands, and executing them on the database.

When you’re performing queries it will take the results of those queries, read the data from them, make instances of our domain classes or models, and push the data in. All of that repetitive work, therefore, is taken care of by an ORM and by Entity Framework.

In short, Entity Framework functions as an abstraction layer. We write our queries in syntax that EF understands and it will convert those queries into optimized database specific syntax. This way, we do not need to concern ourselves with which database provider is being used, whether it is Oracle, SqlServer, MySql, … Entity Framework takes care of the heavy lifting for us so we can focus on other things.

How it works

It all starts with modelling your domain classes or models. You can think of this as all the classes you have converted from your entity relation diagram. Models are often based on real world objects such as a computer, person or order. For example, imagine you have an employee working on one project, but a single project can be worked on by a number of employees. In case of a relational scheme you would model an employee table and a project table, and because of the relation between employee and project you would construct a foreign key in the employee table. In an object oriented model you would create an employee class and a project class:

  class Employee{
        public int ID;
    public string FirstName;
    public string LastName;
    public Project Project
  }
  
  class Project{
   public int ID;
   public string Name;
   public List Employees
  }

With these classes, we can use Entity Framework’s DbContext API to wrap those classes into a model and instruct Entity Framework how those classes map to the database schema. Now Entity Framework can translate queries you write in LINQ to Entities against your classes into SQL that’s understood by your database. It then executes the query and uses the results to return instances of your objects, without plumbing our database connection code ourselves.

With the SaveChanges command, Entity Framework will use the state information to build and execute the insert, update, or delete commands on the database.