Just sharing some of my inconsequential lunch conversations with you... RSS  

Sunday, December 02, 2007

The ADO.NET Entity Framework Overview

My good friend Rui Inácio has just posted and old link about the Entity Framework that is worth some revisiting.

It starts with the reason for the Entity Framework:

Eliminate the impedance mismatch between data models and between languages

It goes on defining:

The Entity Data Model—or EDM for short—is an Entity-Relationship data model. The key concepts introduced by the EDM are:

  • Entity: entities are instances of Entity Types (e.g. Employee, SalesOrder), which are richly structured records with a key. Entities are grouped in Entity-Sets.
  • Relationship: relationships associate entities, and are instances of Relationship Types (e.g. SalesOrder posted-by SalesPerson). Relationships are grouped in Relationship-Sets.

The introduction of an explicit concept of Entity and Relationship allows developers to be much more explicit when describing schemas. In addition to these core concepts, the EDM supports various constructs that further extend its expressivity. For example:

  • Inheritance: entity types can be defined so they inherit from other types (e.g. Employee could inherit from Contact). This kind of inheritance is strictly structural, meaning that there is no "behavior" inherited as it happens in object-oriented programming languages. What's in inherited is the structure of the base entity type; in addition to inheriting its structure, a instances of the derived entity type satisfy the "is a" relationship when tested against the base entity type.
  • Complex types: in addition to the usual scalar types supported by most databases, the EDM supports the definition of complex types and their use as members of entity types. For example, you could define an Address complex type that has StreetAddress, City and State properties and then add a property of type Address to the Contact entity type.

Working on a conceptual level is what we are used to do with NHibernate. When we write a HBM file we express both the conceptual model and the relational database mappings. Int the Entity Framework these models are separated:

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.

In order to provide a mechanism for storing data modeled using the EDM in relational databases, the ADO.NET Entity Framework houses a powerful client-views infrastructure designed to manage the transformations between the logical database schema that's present in the relational store and the conceptual EDM schema used by the application.


The last of the concepts is the Mapping Provider:

Surfacing the EDM and Mapping to the ADO.NET API: The Mapping Provider(now renamed “EntityClient”?)

The EDM and mapping concepts seem to be fairly abstract at first, so at this point one could wonder how they are concretely surfaced in the ADO.NET API.

We 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 EDM model and provides the application with a conceptual view of the data.

Hopefully the next week will bring us a version of the Entity Framework that will be closer to the final release.

No comments:

Development Catharsis :: Copyright 2006 Mário Romano