The ADO.NET Entity Framework is an extended ORM technology from Microsoft. We say it is an extended ORM because it has many additional features compared to a typical ORM. ORMs often use metadata and factory classes to retrieve data or collections of data.

On the contrary, using Entity Framework, you can easily map your data to be accessible in a relational representation in the database to objects, no matter how the mapping is implemented. You can expose different data views to your application without having to change your relational schema. In essence, this allows the applications to have their own view of the data. The applications can even reuse the same views of data among themselves.

The major difference between Entity Framework and ORM tools is the EDM and the former's ability to query data using strongly typed LINQ. You can even use Entity SQL, a T-SQL-like query language to query the EDM, to execute dynamic queries. In addition to what a typical ORM framework provides, the Entity Framework provides and supports entity inheritance, entity composition, and a flexible, loosely-coupled, three-tiered model consisting of the conceptual model, the mapping layer, and the storage model. Please refer to the Appendix section for links to resources on this topic.

Entity Framework even enables you to extend the existing schema. In other words, you can extend the generated entity classes to create your own custom entity classes. You can define relationships of any kind such as one-to-one, one-to-many, and even many-to-many.

LINQ to SQL allows you create an object model that maps to the tables in the relational database. The object relational mapping implementation of LINQ to SQL handles the execution strategy of the SQL queries. A database markup language file, also known as .dbml file, is generated by the Visual Studio IDE when you drag and drop database tables from the solution explorer onto the LINQ to SQL design surface. When each table is dragged on the design surface, a class is created for each table. These classes are known as entity classes and they are partial classes.

Both LINQ to SQL and ORM share certain common behaviors in terms of designing, mapping entities with relational database, and querying entities.

Developing non-LINQ to SQL data-centric applications may consume a lot time and effort in trying to build custom components that will interact with the data source. LINQ to SQL maps tables to classes, which helps architects to design a better n-tier architecture, thus improving productivity.

The properties in the entity classes are mapped to the columns in the table with an appropriate data type mapping scheme. Hence, a compile time check is performed that reduces runtime errors.

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:

Support for persistence ignorance was introduced in Entity Framework 4.0. Persistence ignorance, as the literal meaning implies, is a concept that enables you to build your applications in a way that can just ignore the underlying data store in use. In essence, you can build applications that can have different persistent technology in future.

You can now create your own Plain Old CLR Objects (commonly known as POCO) that are decoupled from any specific persistence technology. To provide support for POCO, all you need to do is just turn off code generation in the model in your Visual Studio 2013 IDE.

You can simply clear the values of the Custom Tool property of your EDM and save it again. Once you have done this, you have to create your own custom object context by deriving your custom object context class from the ObjectContext class. Then you can define the data members and properties in your custom object context class as per your needs.

T4 is a code generation technology that was introduced in Visual Studio 2008. T4 templates not only give you advantage to customize the generated code, they also generate less code, concealing a lot of redundant functions that were present in the old generated code. Entity Framework 6 provides support for T4 code-generation templates. You can also customize these templates as needed.

Lazy loading is a concept that enables an entity to be loaded late— it's loaded on demand actually. Entity Framework 6 provides better support for lazy loading. To enable deferred loading (it is turned off by default), you should make use of the DeferredLoadingEnabled property. Please check out this URL for more information on lazy loading http://msdn.microsoft.com/en-us/library/vstudio/dd456846(v=vs.100).aspx.

Entity Framework 6 enables you to easily track changes to POCOs. Note that Entity Framework 6.0 provides support for the deferred or lazy loading of entities with POCO classes through the usage of proxy types. Here is an example:

var result = (from emp in PayrollDataContext.Employee
.Include("Department") where emp.DepartmentID == 12 select emp).Single();

Please check out this URL to find out more about lazy loading:

http://msdn.microsoft.com/en-us/library/vstudio/dd456846(v=vs.100).aspx

We will explore more about POCO classes and lazy loading later in this book.

Entity Framework 6 provides better n-tier support and support for self-tracking entities. Self-tracking entities are those that enable each entity to track any changes to themselves so that you can pass it across process boundaries and persist the entire object graph. Entity Framework 6 includes T4 templates to generate entities that have the ability to track their own changes on the client side.

Entity Framework 6 now enables you to generate your Data Model from the conceptual model. You can now create your entities and then use Visual Studio 2013 to generate the database based on a predefined conceptual model.

In the code-first approach, the domain model is first defined using POCO classes and then the database is created from these classes. This approach is popular and provides much more control over your code—you just need to define the database mappings and leave the creation of the database entirely to Entity Framework. Note that as your code drives the database, manual changes to the database are not recommended in this approach.

The figure given next illustrates the three approaches and why and when each should be used:

In the model-first approach, you create your entities, relationships, and the inheritance hierarchies directly on the design surface of the EDM Designer in Visual Studio and then generate the database from the model designed. If you need additional features, you can use partial classes. In essence, in this approach, the model drives and defines the database. This is also known as the model-driven approach. This approach is good for small projects, but with complex databases and large projects this is not a preferred approach as you don't have much control over the database. Also, making manual changes to the database schema is also not recommended.

In the database-first approach, you would create your database first and then generate your model using the ADO.NET EDM Designer from this database.

Entity Framework 6 provides support for you to use SQL Server functions directly in your queries. Here is an example:

from emp in PayrollDataContext.Employee
where new[] {"january","february","march"}.Contains(SqlFunctions.DateName("month", emp.JoiningDate))
orderby emp.EmployeeID
select new 
{
 emp.EmployeeID,emp.JoiningDate
};

Entity Framework 6 now provides support for model-defined functions that can be defined in the CSDL using eSQL. Note that model-defined functions support LINQ to Entities and can also be called Object methods. Here is an example:

<Function Name="GetEmployeeAge" ReturnType="Edm.Int32">
    <Parameter Name="Employee" Type="Self.Employee" />
      <DefiningExpression>
        Edm.DiffYears(Employee.BirthDate, Edm.CurrentDateTime())
      </DefiningExpression>
</Function>.

In this section, we just gave you an introduction to the new features in Entity Framework 6—we will cover details of each of these features in the forthcoming chapters of this book.

Enum support is a much-awaited feature that enables you to have enum properties in your domain classes. In Entity Framework 6, you have enum support both in the EF Designer as well as using a code-first approach. To create an enum in Entity Framework 6, all you need is to create a scalar property of type Int32 in the EDM, select it, right-click on it, and then select Convert to Enum. The following image illustrates this:

In the preceding image, IsRetired has been introduced as a scalar property of type Int32. You can see that the Convert to Enum option is enabled.

Spatial data types are actually geography and geometry-related classes that allow us to work directly with such data inside the SQL Server. Spatial data can be of two types—the geometry data type that provides support for planar or Euclidean (flat-earth) data, and geography data type that can store ellipsoidal (round-earth) data such as GPS latitude and longitude coordinates. Entity Framework 6 now provides support for spatial data types using the DbGeography and DbGeometry types. You can include spatial data in your models both using the EF Designer, as well as using code-first. You can find out more about spatial data types from this link: http://technet.microsoft.com/en-us/library/bb964711.aspx.

In Entity Framework 6, DbContext is the default generated context. It is not new though. It is a wrapper around ObjectContext generated using T4 templates. Here is an example:

      public AdventureWorksEntities()
            : base("name=AdventureWorksEntities")
        {
        }
    
        protected override void OnModelCreating(DbModelBuilder 
        modelBuilder)
        {
            throw new UnintentionalCodeFirstException();
        }
    
        public virtual DbSet<Department> Departments { get; set; }
        public virtual DbSet<Employee> Employees { get; set; }
        public virtual DbSet<EmployeeDepartmentHistory> 
        EmployeeDepartmentHistories { get; set; }
        public virtual DbSet<EmployeePayHistory> 
        EmployeePayHistories { get; set; }
        public virtual DbSet<JobCandidate> JobCandidates { get; 
        set; }
        public virtual DbSet<Shift> Shifts { get; set; }
    }

The other enhancements in Entity Framework are shown as follows: