Blog
Overview of the Entity Framework
By Martin Schaeferle | November 18, 2013
Suppose you are designing a database application from scratch. The first thing you do is design the data. What are the things or entities you need to keep track of and what are their relationships? If you are building an order entry system, your list of entities might include customers, orders, products, suppliers, etc. You might then determine that customers place orders and customers can place many orders. Suppliers supply products and suppliers can supply many products. Orders consist of one or more products and each product can be included in one or many orders.
You have now created a conceptual model of your data using an entity-relationship model. The next step in the process is to define how you want to store this information in your data source. What tables will you create and what are their relationships? You might decide to have tables for Customers, Orders, Products, Suppliers, etc. Since orders contain one or more products, you might decide to have an Order Details table. Each of these tables, of course, has a primary key. You then define the foreign key constraints that relate the tables.
The Customers table is related to the Orders table based on the CustomerID column. The Orders table is related to the Order Details table based on the OrderID column. You now have a logical model of your data. The final step is to create the database, the tables, and the constraints that relate the tables. You also create stored procedures in this step. You now have a physical model of your data. The database administrator (DBA) owns and manages the physical model. The DBA creates and maintains the database and defines the stored procedures. The developer owns and manages the application code and writes SQL statements to retrieve and update data.
The developer typically works from the logical model because he or she needs to write SQL statements that reference particular columns in particular tables. To display products and their suppliers, the developer needs to construct a SQL statement that joins the Suppliers and Products tables. Unless the DBA creates stored procedures for every data operation, the developer needs to know how the data is stored. What about the conceptual model? You essentially create it so that you can create the logical and physical models. The DBA works from the physical model and the developer codes to the logical model-no one uses the conceptual model.
However, users think in terms of the conceptual model. When users open the Customers form, they want to see customer information. Whether that resides in one, two, or three database tables is irrelevant. Ideally, the developer would write code based on the conceptual model. If you want to work with customer information, you would create an instance of the Customer class and that class contains customer information. Whether that information resides in one, two, or three database tables should be irrelevant. If you are using ADO.NET the number of tables is not irrelevant because you write the SQL statements to retrieve customer information. If that information resides in three tables, you need to either write a three-table join or execute three SQL statements.
If you are using LINQ to SQL, the number of tables is not irrelevant either. To use LINQ to SQL, you map the structure of a SQL Server database to an object model. Each table in the database maps to a class. So if customer information is in three tables, you need to create three Customer classes and your queries need to account for that. The ADO.NET Entity Framework enables you to write code against the conceptual model rather than the logical model. To work with customers, you work with the Customer class. That class contains all of the customer information, regardless of how that information is stored in the database.
NOTE As of Visual Studio 2008 Service Pack 1 the ADO.NET Entity Framework is included in Visual Studio.
The Entity Data Model is the key to this capability. The Entity Data Model is your object model. It consists of entities, associations, and functions. Entities are your domain objects. These are the things you need to keep track of-for example customers, orders, products, etc. Associations are the relationships between entities. Functions are stored procedures or user-defined functions that you can use to retrieve data. The Entity Data Model is an abstract conceptual model and is not tightly bound to the data source or to the application. In LINQ to SQL, each entity in your object model maps to a table in the database. In the Entity Data Model, you have a variety of possible mappings, such as:
- An entity can map to one table in a database.
- An entity can map to more than one table in a database.
- An entity can map to a table in a SQL Server database and another table in an Oracle database.
- An entity can map to the results of calling a Web service or a Windows Communication Foundation service.
- An entity can map to a table in a database and to the results of calling a Web service.
Customers have information and that information can come from a variety of sources. The Entity Data Model abstracts the physical storage of the information so that all you have to do is create an instance of the Customer class and know that you have access to all the information you need. The Entity Data Model consists of three components:
- Conceptual layer: Defines the conceptual model. What are the entities in the model and how do they relate? This information is stored as XML via the Conceptual Schema Definition Language (CSDL).
- Storage layer: Defines the storage model. How is the data stored in the data source(s)? This information is stored as XML via the Storage Schema Definition Language (SSDL).
- Mapping layer: Defines the mapping between the conceptual and storage models. For each entity, where is the information stored? This information is stored as XML via the Mapping Specification Language (MSL).
In addition to the Entity Data Model, the Entity Framework includes two other key components: the EntityClient Data Provider and Object Services.
- EntityClient Data Provider is responsible for communicating with the underlying data sources. It does this by calling the ADO.NET data providers for each data source. The EntityClient Data Provider translates your conceptual model queries into data source-specific queries and returns a data reader that contains the results of these queries.
- Object Services is responsible for populating entity instances with the results of queries and for tracking changes to data. It enables queries against the conceptual model via either Entity SQL or LINQ to Entities. Entity SQL is a querying language that resembles Transact SQL, but it is outside the scope of this course. LINQ to Entities enables queries that use the familiar LINQ syntax.
