I recently wrote a post on my other blog to demystify Entities in ADO.NET Orcas. In it, I gave the 10,000 foot view of the structure of the various schema files that enable the mapping between your database and the entities which you define in ADO.NET ... and how they all work together.
Mike Dodaro from the ADO.NET team has blogged in more depth about the syntax of these files.
Mike's post is tagged as a “101“ topic. That would make my post about a “50“ and I'd still start there before digging into Mike's.
In addition to the details of the schema, he explains the overall point of “Why Entities?“ nicely and simply:
Existing ORM frameworks tend to address this mismatch by allowing programming classes to be annotated in order to relate them to the database.
The intent with ADO.NET is more ambitious: We view the ORM problem as just one of a number of services we want to build on the database. Other services include reporting, synchronization, backup, and so on. In order to cover all of these services, we have designed a data model that is similar to the object-oriented idiom that programmers use, while remaining independent of any particular programming language or programming platform. This data model is the Entity Data Model (EDM).
The EDM is a conceptual model for designing the data layer of applications. Entities and relationships in the domain of an application are specified in XML syntax. Both the programming classes used in applications and the storage schema map to this conceptual model.
Best of all, he wrote the entire post without using the phrase “Impedance Mismatch”