A few years ago, Microsoft’s Data Access team began showing developers a new direction for ADO.NET, the Entity Framework. This new framework, released in August 2008 as part of Visual Studio 2008 SP1, brings data modeling into the hands of the developers. This version of the Entity Framework is the beginning of a long-term strategy for ADO.NET, and part of a larger data access and modeling strategy for Microsoft’s applications in general.
This article aims to give readers an overview of the ADO.NET Entity Framework, its benefits and some of its current pitfalls as well as an understanding of where the current version fits into the larger picture.
Data modeling vs. the database
Typically, developers must interact directly with the database to get data into and out of the application. This means that you need to have a fairly good understanding of the structure of the database – its tables, views and stored procedures, constraints, schemas and data types, require parameters for stored procedures and the schema of the data that will be returned. Once you have gotten past this barrier, you then need to write plenty of code to reshape the returned data into your application’s objects. If you are writing an application where users can modify data, you then have to extract property values from objects and related data in order to send them back to the data store.
By having a data model at the application level that better represents your business domain objects, the developer can focus on application development, rather than on interacting with the database.
Data modeling at the application level is not a new concept. There are a number of ORM tools available to Visual Studio developers such as nHibernate and ORMapper. Visual Studio’s LINQ to SQL is also a modeling tool which works specifically with SQL Server and leverages the LINQ query language built into C# and Visual Basic.
The ADO.NET Entity Framework differs ORMs in a number of ways
The ADO.NET Entity Framework differs from these ORMs in a number of ways. To begin with, Entity Framework was created so that developers could program against not just any data model, but an Entity Data Model (EDM). The EDM is Microsoft’s realization of Entity Relationship Modeling which has been around for over 35 years. The critical word in there is “relationship”. ERM and EDM define a model by its entities and its relationships. The relationships are first class citizens in this model rather than being metadata about how entities relate to one another. Another critical difference is how Entity Framework is able to move from the conceptual model to the database and back.
The Entity Data Model in Entity Framework
Entity Framework uses an Entity Data Model along with additional metadata that enables your program to automatically figure out how move between objects expressed using the model and the database. Entity Framework includes a set of Visual Studio design tools, including the Entity Data Model Wizard. This wizard allows you to quickly create a model based on an existing database. To demonstrate this, I’ll use a simple SQL Server database as an example, although there are a number of other ADO.NET database providers that now support the Entity Framework (and more that will be released in the future).
Figure 1 shows a diagram of the tables in the example database which describes a simple sales system. The focal point is the Person table. A related SalesPerson table provides additional details about those people who are sales people. In the same way, a Customer table provides additional details about those who are customers. There is an Order table that uses foreign keys to link back to the associated Customer and SalesPerson. Additional details about people and customers are stored in the PersonalDetails and CustomerTypes tables.
Fig. 1: Database schema
Assuming that you instruct the Entity Data Model Wizard to bring in all of the tables from the database, it will create a data model, shown in figure 2, in your application that looks very similar to the database schema.
Fig. 2: Entity Data Model
But looks can be deceiving. If you investigate a bit more closely you may notice that each entity has a set of scalar properties and a set of navigation properties. And if you look even more closely, you will notice that there are no foreign keys. The Order entity has neither a CustomerID property nor a SalesPersonID property; the Customer entity does not have a CustomerTypeID property.
The relationship between one entity and another is not defined by a foreign key, but by a navigation property. The Order entity has a Navigation Property that is a reference to the Customer it is related to. And the Customer entity has an Orders Navigation property that is a reference to the collection of related orders. These are called Navigation Properties because they define how to navigate from one entity to another.
No worries about JOINs
What this means is that you don’t have to worry about using JOINs to connect entities to one another. Entities are naturally bound to one another as you query, as you work with entity objects and as you send data back to the database.
While this EDM is the default data model created by the wizard, there are actually a host of customizations you can do to the model. Figure 3 shows the same model after I have modified it to redefine the Customer and Salesperson entities as derived entities of a Person. You can build inheritance directly into the data model. Additionally, notice in this version of the model that I have combined the Person and PersonalDetail entities into one entity. Even though it points back to two separate tables in the database, I don’t ever have to worry about how that works. Whether I am querying data or modifying it and sending updates back to the database, the Entity Framework will take care of mapping my entities back to the database. I have also renamed some of the Navigation properties so that they are more logical. For example, Customer.Orders was originally Customer.Order, but since that property to many orders, as defined by the 1 to Many (1:*) relationship, the pluralized name is more logical.
Fig. 3: Customized Entity Data Model
There are many more things that you can do to customize a model, from “decorative” changes such as renaming or even removing properties, to architectural changes like building in inheritance.
From the data model to classes
One of the jobs of Entity Framework’s designer is to automatically generate classes from the entities in the model. This is the default behavior and can be overwritten in a variety of ways from writing your own generator to hooking your custom classes into E.F. I’ll focus on the default behavior in this article.
Each entity becomes a class which inherits from EF’s EntityObject class. The EntityObject class provides the entities with the mechanisms they need to plug into the framework. In figure 4, you can see a class diagram showing the Customer entity and its properties along with the properties, methods and interfaces that it inherits from the EntityObject class. Notice that the code generator added a factory method (CreateCustomer) and four change tracking methods to the Customer class.
Fig. 4: Generated customer entity class with its base EntityObject class and E.F. interfaces
With the model and its classes in hand, it’s time to look at some Entity Framework programming features.
Querying against the Entity Data Model
The Entity Framework provides a number of ways to query against the data model. The original query syntax created for this purpose is called Entity SQL. Entity SQL is based on standard SQL query languages but has additional features that enable it to work specifically with the Entity Data Model. As with T-SQL, you construct an Entity SQL query expression as a string and then use Entity Framework’s query mechanisms to execute the query. When querying, you can return objects or simply stream the data back as a DataReader. Underneath the covers, Entity Framework reads the data model and additional metadata to translate the entities and properties in to their related tables and objects, and then communicates with the specific database provider, e.g., SqlClient, to have the EDM query translated into a store command.
Use Entity SQL to return objects or streamed data
The Entity SQL language is very rich with over one hundred operators and functions, allowing you to do all of the standard variations on queries whether you are requesting single entities, shaping data with projections, nesting queries or performing joins.
Querying against the first version of our example EDM, listing 1 shows a simple query that requests person entities while navigating into the related PersonalDetails entity to express a filter.
SELECT VALUE p FROM MyEntities.People as p
WHERE p.PersonalDetails.MaritalStatus=”Married”
ORDERBY p.LastName
Listing 1: Entity SQL using navigation properties
The query in listing 2 uses projection to return shaped data. It begins with Customers, then pulls in the related Person data as well as any Orders that the customer may have. When projection is used, the VALUE keyword is not required.
SELECT c, c.Person, c.Orders FROM MyEntities.Customers as c
Listing 2: Entity SQL projection
EF has two ways to execute an Entity SQL query. The most typically used is the ObjectQuery which will not only cause the query to execute, but will materialize objects from the resulting data. These objects are instantiated from the classes that were generated from the Entity Data Model.
The other mechanism for executing queries is with the EntityClient API which, like other ADO.NET providers, e.g., SqlClient, allows you to create connections and command and return a DbDataReader. In other words, EntityClient returns streamed data and does not materialize objects. This is convenient for tasks such as reporting or moving data around. It differs from using SqlConnections and SqlCommands because the query is expressed in terms of the EDM and the data returned is in the shape of the EDM entities. ObjectQuery execution also uses SQLClient under the covers to execute its queries.
LINQ to Entities
LINQ (Language INtegrated Query) is an enhancement to C# and Visual Basic that was introduced in Visual Studio 2008. When the Entity Framework team first learned about LINQ and saw its querying power, it was obvious that it would be a huge benefit to developers using the Entity Framework. LINQ to Entities is an implementation of LINQ that is particular to working with entities. The entity classes generated from the EDM provide strongly typed classes that allow developers to write queries leveraging strong typing and Intellisense in C# and VB.
The following LINQ queries shown in listings 3 and 4, match the Entity SQL examples above.
==VB==
From p In MyContext.People _
Where p.PersonalDetails.MaritalStatus=”Married”
Order By p.LastName
==C#==
from p in MyContext.People _
where p.PersonalDetails.MaritalStatus==”Married”
order by p.LastName
select p
Listing 3: LINQ to Entities using navigation properties
==VB==
From c In Context.Customers _
Select c, c.Person, c, c.Person, c.Orders
==C#==
from c in Context.Customers _
select c, c.Person, c.Orders
Listing 4: Simple LINQ to Entities projection
LINQ to Entities queries always materialize objects.
Because a LINQ to Entities query is already a query, you don’t need to create a separate query object to execute it as you do with Entity SQL.
Change tracking and updating Entity objects
By default, objects that are created as the result of a query are managed by the Entity Framework’s ObjectContext. This context keeps track of modifications not only to the scalar properties, but also to the relationships between objects.
The ObjectContext has a SaveChanges method which reads all of the changes as well as any new or deleted objects and sends the appropriate commands to the database to perform updates.
If you create new objects under the management of the ObjectContext, it will also take care of relationships. In other words, if you were to create a new Order and a new set of Order Line items in memory, and you specify that the line items are children of that order, the ObjectContext will do the necessary work to automatically insert this graph into the database with the necessary foreign key information.
Between queries and updates
Retrieving data as entities and saving changes back to the data store is only the surface of what Entity Framework provides. Not only do the EF APIs provide a lot of flexibility to modify the behavior of these critical tasks, but the core of the API enables you to work with the instantiated entity objects in a very granular way. You have the ability to create custom business logic throughout the entity classes, control the behavior of how Entity Framework performs its various operations on the instantiated objects and even control transactions and database connections . For both LINQ to Entities and Entity SQL, there are a number of ways to impact performance, from pre-compiling LINQ queries or caching the Entity SQL’s expressions. Using these features means that the expensive task of generating the store query does not need to be repeated.
You can also control how objects are managed by the ObjectContext.
Microsoft’s vision for Entity Framework is large and long-term
Drawbacks of a version one product
Microsoft’s vision for Entity Framework is large and long-term. What we have currently in Visual Studio 2008 is only the first iteration. There are definitely a lot of things about EF today that make it a challenging product for developers to work with. As the architecture of your application becomes more complex, you will need to invest more in understanding and manipulating EF’s underpinnings. Some of the bigger drawbacks in the current version are the limited Stored Procedure support (which should be considered with the understanding that query compilation is one of EF’s core features), challenges with change-tracked entities when you need to move them across tiers (ASP.NET, Web/WCF Services), limitations when working with very large models and lack of support for agile and domain driven design. There are also quite a few technical nuances (i.e. gotchas) that you should be aware of so they don’t surprise you along the way. For example, users of ORM products, including LINQ to SQL, are accustomed to related objects being loaded automatically and might realize surprising results if they assume that Entity Framework does the same — which it does not. Making assumptions about the behavior of relationships between objects can also get you into a pickle, so it’s important to spend some time learning about how methods like attaching, adding and detaching impact the objects.
For many, the prospect of working with the EDM and getting ahead of the curve for aligning with Microsoft’s data strategy is worth the extra effort that it will take to build large, multi-tiered applications with this technology. And there are plenty of developers who are tackling it and working on V1 deployments. While others have chosen to wait until version 2, where there will be vast improvements in the designer, for stored procedures, for n-tier development and for Domain and Agile developers, they are taking advantage of the lead time to start learning the core concepts and ins and outs of EF. Many are designing applications in a way that they will be able to plug EF in to the data layer when they are ready to embed it into their software.
A number of Microsoft tools already lean on Entity Framework, most notable ADO.NET Data Services. You’ll also find technologies like ASP.NET Dynamic Data Controls which are able to rely on an EDM and the Entity Framework for its back-end data.
As more developers learn and use the Entity Framework, you’ll find more and more resources and coding patterns to help you along the way. There are already a lot of resources online and a number of books on Entity Framework at your disposal.