Foreign Keys in the Entity Framework
Background
A number of months ago we asked whether Foreign Keys (FKs) in Conceptual and Object models were important.
The feedback we got indicated that there are a real mix of opinions on the topic. Some people are all for them while others think that FKs pollute the conceptual model.
The fact that our customers were so divided meant we thought it was important to provide options here. Those who want FKs in their Entities should be able to do so, so they can gain all the benefits that having FKs in your Entities undoubtedly provide. On the other hand customers who are concerned that have FKs in their Entities in someway pollutes their model can continue to use the type of associations we had in .NET 3.5 SP1.
In the past we've called the .NET 3.5 SP1 style Associations "first class" associations. Which while accurate somehow implies that associations based on FKs in Entities are "second class". In fact when we talked about this new work recently with our MVPs one of the first questions was "are these second class?", which they most definitely are not.
The fact is these new associations are different but first class nevertheless.
So what's been added?
In .NET 4.0 we will add support for a new type of association called "FK Associations".
The way this works is we will allow you to include your FK columns in your entities as "FK properties", and once you have FK Properties in your entity you can create an "FK Association" that is dependent upon those properties.
Okay so we will have "FK Associations", what are we going to call the older style associations? Obviously saying something like ".NET 3.5 SP1 style Associations" every time isn't ideal. So we are going to call them "Independent Associations".
The term "Independent Association" resonates for us because they are independently mapped, whereas FK Associations need no mapping, simply mapping the Entity(Set) is sufficient.
How do I use an "FK Association"?
The real reason so many customers and partners are asking for "FK Associations" is that they significantly simplify some key coding patterns. So much so that we are convinced that for most people "FK Associations" will be an automatic choice going forward.
Some of the things that are hard with "Independent Associations" are trivially easy using FK Associations. Scenarios as diverse as DataBinding, Dynamic Data, Concurrency Control, ASP.NET MVC Binders, N-Tier etc are all positively impacted.
Let's have a look at some code snippets that will work with "FK Associations":
1) Create a new Product and FK Association to an existing Category by setting the FK Property directly:
using (var context = new Context())
{
//Create a product and a relationship to a known category by ID
Product p = new Product
{
ID = 1,
Name = "Bovril",
CategoryID = 13
};
//Add the product (and create the relationship by FK value)
context.Products.AddObject(p);
context.SaveChanges();
}
This sort of approach works both for insert and update, and is particular useful for things like databinding, where you often have the new Value of the FK in a grid or something but you don't have the corresponding object, and you don't want to wear the cost of a query to pull back the principal object (i.e. the Category).
2) Create a new Product and a new FK Association to an existing Category by setting the reference instead:
public void Create_new_Product_in_existing_Category_by_reference()
{
using (var context = new Context())
{
//Create a new product and relate to an existing category
Product p = new Product
{
ID = 1,
Name = "Bovril",
Category = context.Categories
.Single(c => c.Name == "Food")
};
// Note: no need to add the product, because relating
// to an existing category does that automatically.
// Also notice the use of the Single() query operator
// this is new to EF in .NET 4.0 too.
context.SaveChanges();
}
}
This programming pattern is not new to the Entity Framework, you could do this in .NET 3.5 SP1. I called it out because it shows you can still write the sort of code you write with Independent Associations even when using FK Associations.
3) Update an existing Product without informing the Entity Framework about the original value of the CategoryID (not supported with Independent Associations):
public void Edit(Product editedProduct)
{
using (var context = new Context())
{
// Create a stand-in for the original entity
// by just using the ID. Of the editedProduct
// Note: you don't have to provide an existing Category or CategoryID
context.Products.Attach(
new Product { ID = editedProduct.ID });
// Now update with new values including CategoryID
context.Products.ApplyCurrentValues(editedProduct);
context.SaveChanges();
}
}
In this example "editedProduct" is a product which has been edited somewhere, this is exactly the sort of the code you might write in the Edit method of a ASP.NET MVC controller, and is a great improvement over the code you have to write using Independent Associations.
There is much more you can do with FK Associations, but these 3 samples give you a flavor of the sort of coding patterns FK Associations allow.
Keeping FKs and References in Sync
One thing that hasn't been mentioned so far is that the Entity Framework tries to keep related References and FKs in sync as much as possible.
When this synchronization occurs depends upon when the Entity Framework is notified of changes, which depends upon the type of Entity Classes involved: be they POCO with Proxies, POCO without Proxies, IPOCO or EntityObjects etc.
Another post will cover this in more detail.
How do I create an "FK Association"?
There are a number of ways.
One mainline scenario is when using the tools to infer a model from a database. We have added an option to choose whether "FK Associations" or "Independent Associations" are generated by default. The same is true if you use EdmGen.exe (i.e. our command line tool).
The second mainline scenario for creating FK Associations is creating a model from scratch, aka Model First which is new to .NET 4.0.
Here are the steps involved:
- Create two Entities (say Product and Category) that look something like this:
- Add a property that will be the FK Property: i.e. CategoryID
- Create an association between the two EntityTypes with the correct end multiplicities and NavigationProperty names:
- Double Click the line between the two Entities, that represents the Association, and add a Referential Integrity Constraint:
This is the step that tells the Entity Framework that the CategoryID is an "FK Property" and that the "CategoryProduct" association is an "FK Association".
- You end up with something that looks like this:
And you are done you've set up an FK Association. Notice that this association doesn't need to be mapped you simply need to make sure you map all the properties of both Entities.
Very easy.
Summary
In .NET 4.0 we will add support for FK Properties and FK Associations to the Entity Framework. The existing style Independent Associations will still be possible, but we expect that FK Associations will become most peoples automatic choice because they simplify so many common Entity Framework coding tasks.
As always we'd love to hear your thoughts on this work.
Alex James,
Program Manager, Entity Framework Team, Microsoft.
This post is part of the transparent design exercise in the Entity Framework Team. To understand how it works and how your feedback will be used please look at this post.
