ADO.NET Orcas brings forth a LOT of new concepts, especially for anyone unfamiliar with Object Relational Mapping.

One of the points of confusion is how entities are wired to the database. Now that I understand it, I thought I would use my own way of explaining it to help anyone who might have a hard time with the more deeply technical whitepapers out there.

If you were to follow the typical scenario that is demonstrated in the Entity Data Modeler Hands on Lab, this screencast or this Channel 9 video, you see that you can create an entity set by merely pointing at a database. An entity is generated for each table in the database with a one to one relationship. This isn’t really the optimal scenario for entities, but it’s a great place to get started.

Even if you haven’t installed any of the CTPs, you can look at the various XML files from the October Samples to see what these files look like. I also suggest taking a look at the Next Generation Data Access article on MSDN online for some good visuals to help grok this stuff.

Three XML files are created by the EDM tool.

1. An XML file that represents the schema of the entities. This has the extension of CSDL.
2. An XML file representing the schema of the database that you began with. This has an SSDL extension.
3. An XML file that shows the mapping between elements from the CSDL file and elements in the SSDL file. It’s extension is MSL.

The SSDL file that shows the db schema contains:

An EntityContainer which represents the schema name in the db, such as "dbo". The entity container has elements that are EntitySets. These represent the tables in the database.

EntityTypes are siblings to the EntityContainer element and they represent each table and the schema of the table.

The CSDL that shows the entity schema is somewhat similar:

There is an EntityContainer which has EntitySets and AssociationSets as Children.

Then various EntityTypes flesh out the schemas of each of the EntitySets that live within the Entity Container.

Associations define the relationships between the various entity types.

So if you simply create an entity model directly from the db, the SSDL and CSDL files will look somewhat alike.

Lastly, there is the MSL file, which maps elements of the SSDL to the CSDL files.

Although there is a lot going on in the MSL file, the field mapping happens within EntityTypeMapping elements. Inside of there is a TableMappingFragment element. If you have an entity that is traversing various tables to get it’s data, you would have one EntityTypeMapping for each relationship to a table. Each EntityTypeMapping for this entity will have the same TypeName parameter so that they can be stitched together to create the entire entity.

So if you have an entity such as SalesPerson which gets info from a contacts table, an address table and a HiringInfo table, you would have three separate EntityTypeMapping elements. The first would have a TableMappingFragment that points to the Contacts table. The second points to the Address table and the third to the HiringInfo table. Within each fragment, now we can map the entity’s field to that particular table’s field.

Note: You can create fields in your entity that don’t have anything to map to directly in the db. I still have to learn how these are populated.

Then there’s the magic 🙂

So once these exist, ADO.NET Orcas does a lot of stuff in the background for us. It creates (extensible) classes from the entities that we can code against and when we request data it uses our mapping definitions to pull the correct data from the database. When we want to update, it again, uses the mapping definitions to decide what goes where (and does it very efficiently as you can witness with something like the SQL Server Query profiler). All of this happens in the background, while all we need to interact with is our nicely structured entities.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!