DO.NET provides many rich features that you can use to retrieve data from data sources in a number of ways, but with that flexibility developers sometimes end up tightly coupling their client applications to data sources such as relational databases. This can happen even when developers try to architect their program with a separate data access layer.
In tightly coupled applications the client application has intimate knowledge of the database schema implementationthereby making it extremely difficult to apply the code and concepts to a different area or a different data store, or simply making it difficult or impossible to alter the data store without also altering the application code. The tight coupling isn't always one way; altering the application may require changes to the database as well.
As an example, consider the following data access code, which retrieves the Product
data from the AdventureWorks database.
string connString =
SqlConnection conn = new SqlConnection(connString);
SqlCommand command = conn.CreateCommand();
"Select ProductID, Name from Production.Product";
SqlDataReader reader = sqlCmd.ExecuteReader();
Suppose thatsometime after you've deployed the preceding code into productiona database administrator changes the Name
column from the Product
table to ProductName
. The only way you can prevent the application from breaking is by revisiting the source, making changes to any code that refers to the Name
column, and recompiling, retesting, and redeploying the application. For example, you'd have to change the SQL for the command.CommandText
property from the preceding code to:
"Select ProductID, ProductName from Production.Product";
As there might be many places in the application code that rely on the existing naming scheme, this is a very inflexible implementation, making it difficult to upgrade the application.
To solve this problem, ADO.NET vNext introduces a new layer of abstraction named the Entity Data Model
(EDM). The EDM provides a richer and more intuitive view of the data model from the application's perspective as opposed to the more normalized view of the data as based on optimal storage. Because of this, client applications and the database schema can evolve independentlywithout breaking each other. This article introduces EDM by discussing its design philosophy and showing examples of how you create one. In addition, this article introduces the new mapping provider and Entity SQL features introduced with ADO.NET vNext.
What is ADO.NET vNext?
The EDM and other features are wrapped up into the ADO.NET Entity Framework (called ADO.NET vNext), which includes:
- The Entity Data Model (EDM), which allows developers to model data at higher abstraction levels.
- A powerful client-views/mapping engine to map to and from store schemas.
- Full query support over EDM schemas using a new query language called Entity SQL and LINQ.
- An object services layer that allows you to choose to present query results as either tabular data (rows and columns) or as objects. When using .NET objects, the system transparently performs identity resolution, change tracking, and update processing for you.
- An extensible and open provider model that allows other stores to plug into the ADO.NET Entity Framework.
|Figure 1. ADO.NET Entity Data Model Design: The EDM allows each client application to have its own view of the database, choosing a view that's relevant to the problem domain specific to that application.|
This version of ADO.NET also includes two Language Integrated Query (LINQ) flavors that you may not yet be familiar with:
- LINQ to Entities. Enables you to execute LINQ queries against EDM schemas.
- LINQ to DataSet. Allows you to execute LINQ queries against one or more DataTable objects. The LINQ to DataSet implementation even optimizes certain query patterns for better execution performance.
The core of the ADO.NET Entity Framework is the Entity Data Model, which is essentially a conceptual view of the database schema created by the application developers. Under the covers, this view is described as an XML mapping file in your application, which maps entity properties and relationships to database tables and foreign key (FK) relationships. It's this mapping that abstracts applications from changes to the relational database schema. Rather than changing your application when a change occurs to the database schema, you need only change the XML mapping file to reflect the schema changewithout changing any source code. I'll show you an example later in this article.
As you can see from Figure 1
, you can create any number of application-level database views through the EDM.
illustrates how several applications can create different views (such as a Sales View and a SalesOrders View) of a database through their own entity data models. The specific models enable application developers to work with the database within that application in a way that makes most sense for the business functionality they are trying to provide.