In "Renovations to .NET 4.0's Entity Framework," November 2009, I wrote about a slew of new Entity Framework (EF) 4 features that I was excited about. The article was based on the Beta 1 version of Visual Studio 2010. Beta 2 has finally arrived with some of the expected additions as well as some others that were a nice surprise.

The Beta 2 version of Visual Studio (VS) 2010 and .NET 4, including the EF, is now fairly close to what the final product will be. This article is aimed at bridging the gap between Beta 1 and the release of EF so that you will know what to look for.

Finally, Foreign Keys
As promised by Microsoft, the foreign keys have arrived in the Entity Data Model (EDM). This is an important feature that impacts much of what you do with the EF, so we'll take a close look. The EDM is based on entity relationship modeling (ERM), which does not expose the foreign keys to related objects as a scalar property. Version 1 of EF subscribed closely to this model, where rather than the foreign key ID, you had to work directly with the related object, aka a "value object" in the domain-driven development world.

There are a number of scenarios where not having direct access to the foreign keys caused developers grief. ASP.NET applications rely heavily on foreign keys in the markup and in the code when working with related objects. In certain situations, associations created problems with related objects that had come across tiers. There was also a very common problem for developers when trying to define a relationship where the value object was not instantiated. For example, if you wanted to define a default Customer Type in a Customer entity, many of us are used to simply the default value—for example, 1—to a CustomerTypeID property. However without that foreign key property, EF version 1 required you to code up one of a number of workarounds that did not align with typical coding practices.

The EF team has written about the introduction of foreign keys into the model on their design blog, but that feature didn't make it into Beta 1. In Beta 2, you can see right away in the wizard (Figure 1) that there is a new check box, Include foreign key columns in the model. This is checked by default when you create a model with the wizard. The Entity Framework team believes that most developers will want the foreign keys as properties in their entities.

 
The model will look similar to what you're used to except for the addition of the extra property. Figure 2 shows entities created from the AdventuresWorksLT database, Customer and SalesOrderHeader. The association line between the two still exists as do the navigation properties. The only visual difference is that the CustomerID is now included as a scalar property.

 
Digging a Little Further
As you might expect, the CustomerID property is mapped directly back to the CustomerID column in the database table. What is very different is how the association is defined. If you're familiar with association mappings from version 1, you may recall that the mapping is where the table's CustomerID foreign key came into play. Figure 3 shows the mapping for an association where the CustomerID foreign key is not included in the model.

This was the only option in EF 1.0 and is now referred to as an independent association. The mapping shows that the CustomerID property in the Customer entity (circled in red) maps to the CustomerID column in the SalesOrderHeader database table (circled in yellow). You can still use independent associations in VS 2010, which means that models and applications you created in VS 2008 will still work properly.
 
When the foreign key is present in the entity, there is no longer any association mapping. If you were to right-click the association line, you will no longer find an option to show the mapping. If you open the Mapping Details window and point to the association, you'll see only this message in the mapping window: Mappings are not allowed for an association over exposed foreign keys. This new association is referred to as a Foreign Key association, and you can find more information about it in the Properties Window. The Properties Window for an association has a new property called Referential Constraint, shown in Figure 4.

Although the window shows that the Customer relates to the SalesOrderHeader, it still does not show you how the foreign key ties to the customer entity. Click the value to reveal an ellipsis that will take you to a more telling window where you can define (or view) the constraint in more detail, as Figure 5 shows.

 
This constraint refers to the CustomerID property in the Customer entity and the CustomerID property in the SalesOrderHeader entity. That is how the association between the two is now defined. It also defines the constraint that's checked when it is time to save the entities back to the database, just as EF does when you're using independent associations.

When an entity includes a foreign key, the model relies on that foreign key to work out the relationship to the entity on the other end. This is referred to as a foreign key association. I won't bore you with the raw XML of the model, although that is where my personal interest lies when learning how the model is structured.

Now that you see how the foreign keys work, what can you do with them? When you work with the entities, you'll find that the EntityReference is still created, just as it is with independent associations. The (default) generated SalesOrderHeader class now has the Customer navigation property, the CustomerID scalar property, and the CustomerReference property, as Figure 6 shows.

Entity Framework will keep all three of these in sync. If you change the customer by setting the navigation property [myOrder.Customer=myCustomer], the CustomerID and the CustomerReference.EntityKey will automatically be updated. Whichever of the three you change, the others will sync up. However, the beauty is that you need not have the reference object available. If you set the foreign key [myOrder.CustomerID=24], and there is no instantiated object for that customer, the CustomerReference.EntityKey will still be updated and EF will have all the information it needs to update the database.