Entity Framework architectural components

The Entity Data Model (EDM), an extended entity relationship model, is the core of Entity Framework. You can generate an EDM using the EDMGen.exe command-line tool or using the ADO.NET EDM Designer—a new Visual Studio template. We will discuss how an EDM can be generated from a relational schema in the next chapter.

For additional information, please refer to http://msdn.microsoft.com/en-us/library/bb896270(v=vs.110).aspx.

The following image illustrates where exactly the EDM fits in:

The Entity Data Model

The EDM abstracts the logical or the relational schema and exposes the conceptual schema of the data using a three-layered approach. It comprises the following layers:

The following image illustrates the layers of the EDM:

The Entity Data Model layers

Let's explain each of these layers in detail:

Here is what a typical EDM looks like:

An ADO.NET Entity Data Model at a glance

The EDM uses the following three types of XML files to represent the C-Space, C-S Space, and the S-Space respectively:

These files store the metadata information as XML for each of the preceding layers.

We will skip further discussion on each of the sections of an EDM until Chapter 3, Entities, Relationships, and the Entity Data Model.

When working with Entity Framework, you will have an Object Model on top of all the EDM layers. You need to model the Object Model using .NET objects. The following figure illustrates how the Object Model fits in with the EDM layers:

The Object Model and its relationship with other layers

The Object Model layer contains .NET objects and a collection of .NET objects, types, properties, and methods. You can use the Object Model or the O-Space Model to query your business objects, or the collections of your business objects, using LINQ to Entities or Entity SQL. The C-Space and O-Space models are actually mapped by the O-C Mapping Layer using code attributes applied to the O-Space Model.

LINQ is a query translation pipeline that has been introduced as part of the C# 3.0 library. It comprises a set of query operators for different data sources (LDAP, objects, CSV, XML, entities, SQL, and so on). It is an extension of the C# language (it's actually a series of extension methods) and provides a simplified framework to access relational data in a strongly typed, object-oriented manner.

LINQ to Entities is a Microsoft technology that enables you to query your business objects from within the language in a strongly typed manner. You can use LINQ to Entities, a superset of LINQ to SQL, to query data against a conceptual data model, namely, the Entity Data Model. You will learn more about LINQ and LINQ to Entities in Chapter 6, Working with LINQ to Entities.

Here is an example of a typical LINQ to Entities query:

AdventureWorksEntities ctx = new AdventureWorksEntities();
            var query = from e in ctx.Employees
               select e;
            foreach (var employee in query)
                Console.WriteLine (employee.EmployeeID);

The Entity Framework allows you to write programs against the EDM and also add a level of abstraction on top of the relational model. This isolation of the logical view of data from the Object Model is accomplished by expressing queries in terms of abstractions using an enhanced query language called Entity SQL.

EntityClient, the gateway to entity-level queries, is the Entity Framework's counterpart of ADO.NET's SQL client or Oracle client that uses Entity SQL or E-SQL to query the conceptual model. You create a connection using the entity connection, execute commands through entity commands, and retrieve the result sets as entity data readers. The MSDN states:

Entity SQL is a data store independent derivative of T-SQL that supports entity inheritance and relationships. You can use it to query data using the conceptual schema. You can even build your own dynamic queries. These E-SQL queries are internally translated to data store dependent SQL queries. This translation of the E-SQL queries to their data store-specific query language like T-SQL, (it doesn't need to be only T-SQL, however, it is the supported one), is handled by the Entity Framework. Entity SQL or E-SQL may not be as strongly typed as LINQ is, but you have the flexibility of executing dynamic queries using it, much like T-SQL.

But, why do you need Entity SQL when you have LINQ to Entities to query data through your EDM? You can, using Entity SQL, compose queries that are difficult to determine until the time the query is executed. On a different note, Entity SQL is a full text-based query language that you can use in much the same way as you use the ADO.NET data providers.

Here is an example that shows how you can use Entity SQL to insert data into your applications:

using (EntityConnection conn = new 
EntityConnection("Name=PayrollEntities"))
            {
                try
                {
                    conn.Open();
                    EntityCommand cmd = conn.CreateCommand();
                    cmd.CommandText = 
                    "PayrollEntities.AddNewEmployee";
                    cmd.CommandType = CommandType.StoredProcedure;
                    cmd.Parameters.AddWithValue("FirstName", 
                    "Joydip");
                    cmd.Parameters.AddWithValue("LastName", 
                    "Kanjilal");
                    cmd.Parameters.AddWithValue("Address", 
                    "Hyderabad");
                    cmd.Parameters.AddWithValue("DepartmentID", 
                    4);
                    cmd.ExecuteNonQuery();
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.ToString());
                }
            }

Select Employee.FirstName, Employee.LastName, Department.DepartmentName, Salary.Basic
from Employee
INNER JOIN 
Department on Department.DepartmentID = Employee.DepartmentID
INNER JOIN
Salary on Salary.EmployeeID = Employee.EmployeeID

Select FirstName, LastName, DepartmentName, Basic from Employee

As well as querying the conceptual model, you might, at some point, have to work with entities such as in-memory objects or a collection of in-memory objects. To do this, you need Object Services. You can use it to query data from almost any data store, and with less code.

Note that the Object Services Layer internally uses an ObjectQuery object for query processing. To use object services, you should include the System.Data.Objects and System.Data.Objects.DataClasses namespaces.

Here is an example that shows how you can use Object Services to retrieve data:

using (ObjectContext ctx = new ObjectContext("Name= PayrollEntities"))
            {
                ObjectQuery<Employee> data = ctx.CreateQuery<Employee>("PayrollEntities.Employees");

                foreach (Employee emp in data)
                {
                    Console.WriteLine(emp.EmployeeID);
                }
            }

In addition to enabling you to perform create, read, update, and delete (CRUD) operations, the Object Services Layer provides the following additional services:

You will learn more about Object Services later in the book. The Object Services Layer leverages an Object Query object internally to process the data. Note that the Object Services Layer supports querying data using both Entity SQL and LINQ to Entities.

Here is a quick look at some of the features and benefits of Entity Framework: