Entity Framework is an Object Relational Mapper (ORM) from Microsoft that lets the application’s developers work with relational data as business models. It eliminates the need for most of the plumbing code that developers write (while using ADO.NET) for data access. Entity Framework provides a comprehensive, model-based system that makes the creation of a data access layer very easy for the developers by freeing them from writing similar data access code for all the domain models. The initial release of Entity Framework was Entity Framework 3.5. It was released with .NET Framework 3.5 SP1 and Visual Studio 2008 SP1. Entity Framework has evolved a lot since then, and the current version is 6.0.
Entity Framework eases the task of creating a data access layer by enabling the access of data, by representing the data as a conceptual model, that is, a set of entities and relationships. The application can perform the basic CRUD (create, read, update, and delete) operations and easily manage one-to-one, one-to-many, and many-to-many relationships between the entities.
Here are a few benefits of using Entity Framework:
The development time is reduced since the developers don’t have to write all the ADO.NET plumbing code needed for data access
We can have all the data access logic written in a higher-level language such as C# rather than writing SQL queries and stored procedures
Since the database tables cannot have advanced relationships (inheritance) as the domain entities can, the business model, that is, the conceptual model can be used to suit the application domain using relationships among the entities.
The underlying data store can be replaced relatively easily if we use an ORM since all the data access logic is present in our application instead of the data layer. If an ORM is not being used, it would be comparatively difficult to do so.
Let’s try to visualize the Entity Framework architecture:
From the preceding diagram, we can see that Entity Framework is written on top of the ADO.NET framework, and underneath, it is still using the ADO.NET methods and classes to perform the data operations.
Entity Framework modeling and persistence
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.
Understanding the Entity Data Model
The conceptual data model is the heart of Entity Framework. To use Entity Framework, we have to create the conceptual data model, that is, the EDM. The EDM defines our conceptual model classes, the relationships between those classes, and the mapping of those models to the database schema.
Once our EDM is created, we can perform all the CRUD operations (create, retrieve, update, and delete) on our conceptual model, and Entity Framework will translate all these object queries to database queries (SQL). Once these queries are executed, the results will again be converted to conceptual model object instances by Entity Framework. Entity Framework will use the mapping information stored in the EDM to perform this translation of object queries to SQL queries, and the relational data to conceptual models.
Once our EDM is ready, we can perform the CRUD operations using the model objects. To be able to perform the CRUD operations, we have to use the ObjectContext class. Let’s try to understand what the ObjectContext class is and how it can be used to perform the CRUD operations.
Understanding the ObjectContext class
Once I have my EDM created, I will have all the entities that I can use in my application. However, I still need a central arbitrator that will let me perform various operations on these entities. This arbitrator in Entity Framework is the ObjectContext class.
The ObjectContext class is the main object in Entity Framework. It is the class that is responsible for:
Managing database connection
Providing support to perform CRUD operations
Keeping track of changes in the models so that the models can be updated in the database
The ObjectContext class can be thought of as an orchestrator that will manage all the entities in the EDM, and lets us perform all of the database operations for these entities.
The ObjectContext class has a SaveChanges method that we have to call when we want to save the new or changed objects to the database.
Development styles and different Entity Framework approaches
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:
Database First: This is the approach that will be used with an existing database schema. In this approach, the EDM will be created from the database schema. This approach is best suited for applications that use an already existing database.
Code First: This is the approach where all the domain models are written in the form of classes. These classes will constitute our EDM. The database schema will be created from these models. This approach is best suited for applications that are highly domain-centric and will have the domain model classes created first. The database here is needed only as a persistence mechanism for these domain models.
Model First: This approach is very similar to the Code First approach, but in this case, we use a visual EDM designer to design our models. The database schema and the classes will be generated by this conceptual model. The model will give us the SQL statements needed to create the database, and we can use it to create our database and connect up with our application. For all practical purposes, it’s the same as the Code First approach, but in this approach, we have the visual EDM designer available.
Comparing the 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.
The Database First approach
In a Database First approach, the main benefit that the developers have is that if the database is created, they will spend very little time writing the data access layer. The EDM can be created from the database and then we can change it as per our application needs; our data access layer is ready to use. Here are a few scenarios where the Database First approach is very useful:
When we are working with a legacy database.
When we are working in a scenario where the database design is being done by another team of DBAs, and once the database is ready, the application development starts.
When we are working on a data centric application, that is, the application domain model is the database itself, and it is being changed frequently to cater to new requirements. For instance, when the tables are being updated regularly and new columns are being added to it frequently then we can simply use this approach, and the application code will not break. We simply have to write the code to cater to the newly added columns.
The Model First approach
Similar to the Database First approach, in the Model First approach, we ultimately end up with the EDM. Using this EDM, we can create our conceptual model and the database. The only reason to choose the Model First approach is that we really want to use the Visual Entity Designer. There is no other strong reason to choose this approach over the other two.
The Code First approach
The Code First approach is usually helpful where all the business logic is implemented in terms of classes, and the database is simply being used as a persistence mechanism for these models. Here are a few reasons why one might want to choose the Code First approach:
The database is simply a persistence mechanism for the models, that is, no logic is in the database.
Full control over the code, that is, there is no auto-generated model and context code.
The database will not be changed manually. The model classes will always change and based on this, the database should change itself.
References:
Mastering Entity Framework
By: Rahul Rahul Rajat Singh Singh