At the MVP summit, we saw a presentation on the introduction of FKs into the EF metadata and framework. While they go a long way to solve the many problems of using Entities across tiers, you will now have an either/or choice to make with your model.

When building a model, you will now choose between associations and foreign keys ("FK Associations"). I had a big problem with this when I saw it because it takes a giant step away from Entity Relationship Modeling and much of what we know about EF's conceptual model. On the other hand - purist or realist - it will get us out of the terrible hole we are in currently with all of the rules and regulations around building graphs in EF. There are a lot of surprises that can occur if you are not deeply invested in understanding how relationships work in Entity Framework. Also, there are places where you just need the Foreign Key. I have found this to be a big issue when working with web applications and therefore have added a FK setter & getter property into some of my entity's partial classes.

So now you will have to choose, and most likely people will choose the route that won't cause them to pull their hair out. It still bothers me that it is an either/or scenario, but apparently there was no way to solve these problems when using associations.

Alex James has written an in=depth blog post about how FK Associations will work in VS2010 over here: Foreign Keys in the Entity Framework.