ADO.NET Entity Framework Whitepaper - More About the Entity Data Model Goodness
by David Hayden ( Florida ASP.NET C# SQL Server Developer )
The ADO.NET Entity Framework Overview Whitepaper from Microsoft came out several weeks ago, but today I got my first chance to read it. If you enjoy the subjects of ADO.NET, Object-Relational Mapping, and data access, you will definitely enjoy reading how Microsoft is attempting to free our database applications from the confines of the database schema. With the ADO.NET Entity Framework, we will now enjoy a view of the database schema that is more appropriate for our application - called the Entity Data Model.
If you don't feel like reading the whitepaper, I recommend watching the screencasts that I mentioned in the following post:
The screencasts cover the same information, but show it in action. I also provide a summary of the screencasts in the post.
Here are some of my notes on the new ADO.NET Entity Framework from the whitepaper:
- 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.
- Code using the ADO Entity Framework offers:
- No artificial constructs. It's common to see applications that need to adapt to peculiarities of the underlying store schema. For example, applications built on top of relational databases often have to make extensive use of joins in order to navigate through relationships. In the code above, in contrast, the "shape" of the data follows the abstractions of the problem being modeled; there are "orders", which have "order lines" and that are related to a "sales person".
- No plumbing. The code is very database intensive, yet there are no database connection objects, no external language such as SQL for query formulation, no parameter binding, no configuration embedded in code. In this sense, you could say this code is "pure business logic".
- The problem is the fact that the database schema is not always the right view of the data for a given application. The Entity Data Model maps the database schema much closer to the view that a sales application would use for its store.
- The Entity Data Model uses an XML File created with the Schema Description Language ( SDL ) to map the conceptual Entity Data Model to the Database Schema.
- Microsoft chose to introduce a new data-access provider for ADO.NET called the "mapping provider". Just like a regular provider connects to a store and provides the application with a view of the store data in its logical schema, the mapping provider connects to a conceptual Entity Data Model and provides the application with a conceptual view of the data.
- The ADO.NET Entity Framework introduces a query language that's designed to work with the EDM and can leverage the full expressivity of the entity data model. The language is called Entity SQL.
- For developers that do not require mapping to a conceptual model, LINQ to SQL (formerly known as DLinq) enables developers to experience the LINQ programming model directly over existing database schema.
Exciting times.
Note that I mention ADO.NET 3.0 in a couple of titles, but Microsoft hasn't suggested an ADO.NET 3.0. I am being presumptuous, so ignore the reference :) I'll avoid it in the future.
Other ADO.NET Entity Framework Articles:
Source: David Hayden ( Florida ASP.NET C# SQL Server Developer )
Filed: ADO.NET Entity Framework