Recently I decided to roll up my sleeves and demystify the workings of the Entity Framework. I had taken a look at it a while back but found the tooling a little premature, so I put it back on the shelf and carried on bashing away with LinQ to SQL which to my mind “did everything that Entity Framework does”. Boy was I wrong!

This is the first of a multi part series that will take us from EF Noobs to Pirate Ninja EF Ubersoldata. But first. The basics.

What is EF?

Simply put, the Entity Framework is an object relational mapper. That is it takes database objects like tables, sprocs, views, etc and maps them into a nice easy to use object model that can be called in code. If done correctly, this should take the nightmare out of managing the translation of SQL types and structures into CLR types. Entity Framework off this and SO much more.


The basic architecture of Entity Framework is similar to most ORM mappers. The DataContext is a class that holds all the meta data about the model as well as the entity definitions. The DataContext is broken up into three physical layers that aid the transformation from the data layer into the conceptual layer. These three layers are the Conceptual Layer, Storage Layer and the Mapping Layer. Any data changes (CRUD, etc) made in the Conceptual Layer are passed through the mapping layer and mapped onto SQL commands, generated dynamically or called via procs. This gives us a powerful mechanism to perform some advanced operations with the complexity abstracted from the developer. These include:

  • Inheritance scenarios
  • Data splitting scenarios
  • Data composition scenarios
  • Parent / Child awareness in the conceptual layer
  • Renaming and remapping of database entities.
  • Allows strong typed set based operations in code

CSDL: Conceptual Layer

The conceptual layer is a layer whose functionality maps closely onto your applications functionality. Moreover, since we can have multiple Data Contexts, it gives us the ability to map our conceptual layer closely with our problem domain and remove the nuances of having to handle database specific issues in our code. We can target multiple EDMX files to different parts of the system.

SSDL: Store Layer

The Storage layer maps directly onto the database structure. Since this layer has semantic knowledge of the database, it can perform code generation for most database scenarios at runtime. You may map most database entities in the Store layer and bubble them up to the Conceptual Layer. This includes:

  • Tables
  • Views
  • Stored Procs
  • Functions

In some more advanced scenarios you are permitted to define SQL commands in your store and treat them as first class Store elements

MSDL: Mapping Layer

The Mapping Layer ties the Conceptual and Store layers together and handles translations between the two. The existence of this layer allows us some complex binding and mapping scenarios (These will be outlined later on) There are several options when mapping entities:

  • Procs to CLR methods
  • CRUD through auto generated SQL
  • CRUD though stored proc to entity mapping

The EDMX and Code Generation

When creating a new entity data model is created, in fact what happens is the designer tool generates an XML file (.EDMX). We can explore this file by opening the EDMX file in an XML editor. From there you can clearly see the three sections: CSDL, SSDL and MSDL. There is also a fourth section for the designer to track the graphical objects on the design surface.

Using T4 template code generation the XML is parsed and the code behind is generated. This code behind file includes the classes for the three layers as well as the data context. Since T4 code generation is used, we can change the T4 template to use a custom template if we want to modify or extend the generated classes. Out the box the generator creates a Table per Type inheritance strategy with table mappings and all entity classes deriving off the EntityObject class. We will see how to change these behaviors later on.

Model First vs Data First

The Visual Studio 2010 tooling provides a rich modelling environment. We are given two options to create the data model.

  • Model First
  • Generate from Existing Database

Model first allows us to play with the designer and let us generate a database off the model. It abstracts some of the noramlization concerns like associative entities. This is a very natural way for a developer to work. From this we can specify some database options like schema namespace, properties that enlist in concurrency checking, etc. At this stage all your work resides on the conceptual layer. Given this it has enough information to generate a new database script. Use this method when designing a new system from scratch as it employs some best practices that are often overlooked. Once generated, the designer then populates its store layer and mapping layer to map onto the newly created database.

Generate from existing database does exactly what it says. It will go through the database and extract database objects and build the model from the store layer upwards. Once complete, you may remove entities from the conceptual layer and be prompted if you would like to remove from the mapping and store layer accordingly. In some cases you want items to exist in the store layer but mapped/remapped to one or more entities in the conceptual layer. You may also choose to update the model from the database as it changes over time.

In part 2 we will be diving into some code and basic examples.

  1. […] getting started with the Entity Framework follow my multi part tutorial Possibly related posts: (automatically generated)A Deeper Dive into ADO.NET Entity Framework Part […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s