When one takes a look at the amount of code that the average application developer must write to address the impedance mismatch across various data representations (for example objects and relational stores) it is clear that there is an opportunity for improvement. Indeed, there are many scenarios where the right framework can empower an application developer to focus on the needs of the application as opposed to the complexities of bridging disparate data representations.A primary goal of the upcoming version of ADO.NET is to raise the level of abstraction for data programming, thus helping to eliminate the impedance mismatch between data models and between languages that application developers would otherwise have to deal with. Two innovations that make this move possible are Language-Integrated Query and the ADO.NET Entity Framework. The Entity Framework exists as a new part of the ADO.NET family of technologies. ADO.NET will LINQ-enable many data access components: LINQ to SQL, LINQ to DataSet and LINQ to Entities.
The ADO.NET Entity Framework: Modeling at the Right Level of Abstraction
Every business application has, explicitly or implicitly, a conceptual data model that describes the various elements of the problem domain, as well as each element's structure, the relationships between each element, their constraints, and so on.
Figure 1
If we were building a human-resources application on top of this database and at some point wanted to find all of the full-time employees that were hired during 2006 and list their names and titles, we'd have to write the following SQL query:
SELECT c.FirstName, e.Title FROM Employee e INNER JOIN Contact c ON e.EmployeeID = c.ContactID
WHERE e.SalariedFlag = 1 AND e.HireDate >= '2006-01-01'
Modeling Data at the Conceptual Level of Abstraction: The Entity Data Model
In order to address the first issue identified in the previous section what we need is a way of describing the data structure (the schema) that uses higher-level constructs.
Figure 2
In plain English this schema has the following elements:
- Three entity types: SalesPerson, SalesOrder and StoreSalesOrder. Note that StoreSalesOrder "is a" SalesOrder (in inherits from SalesOrder), with the special characteristic of having tax information.
- A relationship between the SalesOrder and the SalesPerson entity types
- Two entity-sets: SalesOrders and SalesPeople; note that the SalesOrders entity-set can have instances of both SalesOrder and StoreSalesOrder entity types.
To provide a concrete example, in the previous section we needed a 3-way join to access the names of the sales people in a query, something like:
SELECT sp.FirstName, sp.LastName, sp.HireDate FROM SalesPerson sp INNER JOIN Employee e ON sp.SalesPersonID = e.EmployeeID INNER JOIN Contact c ON e.EmployeeID = c.ContactID WHERE e.SalariedFlag = 1 AND e.HireDate >= '2006-01-01'
Bringing Data into an EDM Model: Mapping
The EDM is a conceptual data model that can be used to model the data of a given domain. However, at some point the data needs to be stored in an actual database, typically a relational database.
To continue with the example, if we wanted to map the logical database schema that we used at the beginning of this section to the conceptual EDM schema of the previous section, we'd do something like this:
Querying Against an EDM Model: Entity SQL
When an application uses an EDM model and the mapping provider to access it, it no longer connects directly to a database or sees any database-specific construct; the entire application operates in terms of the higher-level EDM model.
0 comments:
Post a Comment