Foreign Keys in the Entity Framework

Click & Solve » Foreign Keys in the Entity Framework

Click & Solve » Foreign Keys in the Entity Framework — Tue, 17 Mar 2009 00:00:52 GMT

PingBack from http://www.clickandsolve.com/?p=23814

Entity Framework Design : Foreign Keys in the Entity Framework

DotNetShoutout — Tue, 17 Mar 2009 02:33:40 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Foreign Keys in the Entity Framework

Michael Hart — Tue, 17 Mar 2009 05:52:55 GMT

Code snippet #3, with the editedProduct doesn't seem to make much sense to me.

Where does newProduct come from? Shouldn't you just attach the editedProduct directly (which will have the updated Category/ID in it)?

re: Foreign Keys in the Entity Framework

Alex James — Tue, 17 Mar 2009 06:05:47 GMT

Michael,

there was a typo... it was suppose to be editedProduct...

Let me know if it still doesn't make sense

Cheers

Alex

re: Foreign Keys in the Entity Framework

KristoferA — Tue, 17 Mar 2009 07:00:15 GMT

I'm with Michael here - why not context.Products.Attach(editedProduct); ?

re: Foreign Keys in the Entity Framework

cravier — Tue, 17 Mar 2009 12:47:12 GMT

Really good news !

I had to manage this on current EF release and it gave me a big headhache to keep FK and references sync.

I still have some problems (setting FKs in constructor for example) but I'll now wait for next release instead of adding some code in my framework.

Chris

re: Foreign Keys in the Entity Framework

efdesign — Tue, 17 Mar 2009 20:01:44 GMT

Kristofer and Michael,

The idea is to create a fake entity and attach that, to save the query to the database. And then to modify that with the values, including the FK value, in editedProduct with a call to ApplyCurrentValues().

At this point the EF knows the new state of the product and knows that it is modified.

Does that make sense?

Alex

re: Foreign Keys in the Entity Framework

KristoferA — Wed, 18 Mar 2009 07:23:29 GMT

But you can do that by attaching the existing editedProduct instance too.

It is a basic n-tier scenario; get object, serialize/disconnect, do stuff, re-attach, update. Much cleaner if it can be done in one step IMO...

re: Foreign Keys in the Entity Framework

Mike Borozdin — Thu, 19 Mar 2009 00:05:39 GMT

Alex,

Good work! I'm really happy that the new version of the Entity Framework will a lot better and easy to use than the current version.

Currently, I'm working with the version in .NET 3.5 SP1 it provides a really great level of abstraction, but sometimes it's difficult to write code mainly because of absense of foreign keys in the conceptual model.

Новая версия Entity Framework будет поддерживать внешние ключи в концептуальной

Mike Borozdin — Thu, 19 Mar 2009 00:29:37 GMT

Многие, кто сейчас работают с Entity Framework, жалуются на отсутствие внешних к

re: Foreign Keys in the Entity Framework

shawn — Fri, 20 Mar 2009 22:51:20 GMT

Great to hear this, it will make dealing with foreign keys much easier!

re: Foreign Keys in the Entity Framework

Jon — Mon, 23 Mar 2009 21:44:32 GMT

Does anyone know if Entity Framework will be usable in .NET 4? Or, is this blog just a bunch of hot air for another Microsoft ORM that will never see the light of day? What about generating the database schema from the model? Is that going to be supported? Why can't Microsoft get this stuff right and somehow open source projects like NHibernate are able to figure it out? I don't know why EF was even included in .NET 3.5.

re: Foreign Keys in the Entity Framework

AlexJ — Tue, 24 Mar 2009 00:57:45 GMT

Jon,

Generating a database from a model is a supported scenario in the next version of the Entity Framework (.NET 4.0) see the post on "Model First" on this blog.

As for your other concerns and questions. we know we didn't get everything right in .NET 3.5, but we are listening to what our customers have been saying and are doing our best to rectify the situation for .NET 4.0, which will be a major improvement.

Other than "model first" have you got any specific concerns with the first version of the Entity Framework? If so I'd love to hear from you. My email is alexj at microsoft dot com.

Cheers

Alex

New posts on EF Design Blog

Jaroslaw Kowalski — Tue, 24 Mar 2009 05:42:13 GMT

I’d like to turn your attention to two blog posts on EF Design Blog about exciting new features planned

re: Foreign Keys in the Entity Framework

Y2Kstephen — Wed, 25 Mar 2009 05:25:57 GMT

GREAT !!!

i can't wait any longer for .NET 4.0 !!!

Tip 7 - Faking Foreign Key Properties in .NET 3.5 SP1

Meta-Me — Wed, 25 Mar 2009 05:43:36 GMT

Background If you've been reading the EF Design Blog you will have seen that we recently announced something

Tip 9 – Deleting an object without retrieving it

Meta-Me — Fri, 27 Mar 2009 08:38:58 GMT

Problem The most common way to delete an Entity in the Entity Framework is to pull the Entity you want

Schema et accès aux données

Les news d'Aspectize — Tue, 31 Mar 2009 09:54:00 GMT

Cet article a pour objectif de décrire notre approche à propos de l'accès aux données. En préambule

Tip 10 - Understanding Entity Framework jargon

Meta-Me — Fri, 03 Apr 2009 07:41:12 GMT

The Entity Framework is pretty big, so when the Entity Framework team talks about things internally we

An analogy: Good UI and Fluent APIs

Meta-Me — Thu, 16 Apr 2009 22:27:09 GMT

Background A while back I was writing a web app to try the Entity Framework and MVC together. I knew

re: Foreign Keys in the Entity Framework

Baum — Sun, 10 May 2009 00:41:15 GMT

Are there any plans for Microsoft to include EF 2.0 support for databases other than SQL Server such as Oracle or DB2. I know that there is a 3rd part provider that allows EF 1.0 to work with Oracle, but it would be nice if Microsoft provided support out-of-the-box.

re: Foreign Keys in the Entity Framework

Daniel Simmons — Thu, 14 May 2009 17:33:30 GMT

@Baum,

There are not plans for Microsoft to ship EF providers for databases outside of the SQL family--except for some work that the Host Integration Server team is doing around DB2. For databases such as Oracle, we will depend on 3rd parties (or Oracle itself) to create those providers.

- Danny

re: Foreign Keys in the Entity Framework

Alexander Walker — Sun, 14 Jun 2009 19:17:27 GMT

I'm using vs2010 beta 1. I created a .net 4.0 console project, added an empty ADO.NET Entity Model, then performed the steps detailed above for FK Associations for the Model First scenario. I found that I could not make the foreign key association in step 4, the CategoryID was not in the Dependant Property dropdown and typing it in didn't work either, is this a bug or did I miss something out?

re: Foreign Keys in the Entity Framework

divega@microsoft.com — Sun, 14 Jun 2009 19:41:11 GMT

@Alexander,

Beta 1 doesn’t actually include support for Foreign Key Associations. You can expect the feature to be there in the next publically available release.

Thanks,

Diego

re: Foreign Keys in the Entity Framework

Paul — Thu, 18 Jun 2009 22:17:27 GMT

Thanks for the interesting information.

Will it be possibly for the EF to generate the FK properties automatically? If you have a huge data model this will be a big hassle.

Maybe, I'm a special case because we have our own data layer, but I'm fundamentally interested in having classes generated that can be mapped directly onto the underlying data columns.

Currently, I've been trying to figure out how to have the current entity framework completely ignore foreign key associations. Anybody know if this is possible?

Thanks,

Paul

Tip 26 – How to avoid database queries using Stub Entities

Meta-Me — Fri, 19 Jun 2009 21:00:41 GMT

What are Stub Entities? A stub entity is a partially populated entity that stands in for the real thing.

Tip 26 – How to avoid database queries using Stub Entities

VS2010学习 — Sat, 20 Jun 2009 05:36:12 GMT

What are Stub Entities? A stub entity is a partially populated entity that stands in for the real thing

Tip 10 - How to understand Entity Framework jargon

VS2010学习 — Sun, 21 Jun 2009 21:30:55 GMT

The Entity Framework is pretty big, so when the Entity Framework team talks about things internally we

Tip 9 – How to delete an object without retrieving it

VS2010学习 — Sun, 21 Jun 2009 21:31:54 GMT

Problem The most common way to delete an Entity in the Entity Framework is to pull the Entity you want

re: Foreign Keys in the Entity Framework

Dmitry — Sat, 11 Jul 2009 08:36:52 GMT

I think a better way to go about this would be to be able to create entity proxies that only have the ID/primary key properties populated. Once you access another property, it would load the entity data from the database. This way you can assign relations without hitting the database or redundant properties.

re: Foreign Keys in the Entity Framework

Fedir — Mon, 14 Sep 2009 20:42:28 GMT

I've tried to use the "FK Association" in the VS2010 Beta1 and DataServices CTP2 release - it doesn't work as were outlined in this article. You can't create an FK association on the dependent object property if its not a part of the entity key!? Why this was changed and how can I work with the "FK association" now?

re: Foreign Keys in the Entity Framework

Daniel Simmons — Mon, 14 Sep 2009 22:50:28 GMT

#Fedir,

This wasn't "changed". This feature just hasn't been released yet. FK Associations will be in beta 2 of VS2010, but it hadn't yet made it into the product as of beta 1. Sorry, but you have a little while to wait yet.

- Danny

re: Foreign Keys in the Entity Framework

Andrey — Mon, 12 Oct 2009 10:03:29 GMT

If I've not missed something, so please note that IObjectSet in Beta1 contains small amount of possible methods from ObjectSet, so the scenario #3 could not be covered unit tests (by mocking ObjectSet) at all because of using ApplyCurrentValues method. Is it possible to enlarge IObjectSet interface with that methods or introduce new interface for that.

Thanks.

re: Foreign Keys in the Entity Framework

Aquilax — Tue, 13 Oct 2009 08:20:03 GMT

I hope this will also improve the performance of the Data Services. Actually the Data Services doesn't include any information about related object / foreign keys, to have them you have to $expand the relation, what sometimes generate only a bigger response and it is useless.

For example I want to load a product, on the client I have already loaded all the available product categories, so I really don't need to $expand the product category relation to have it but if I don't do it I don't have it.

Now if my product have 6 different relations to some mapping tables (which I have already loaded on the client) and I show 20 products per page, the Data Services includes to each request 20x6=120 completely useless informations, which make only the response bigger and worse the performance of the application.

Instead of the foreign key could have also been used a "ghost" entity, which contains only the primary key. A "ghost" entity can interpreted as "this entity exists but it has not yet materialized". So loading entities from the DB without including referenced entities will generated "ghost" entities for all the relations which are not null.

So for example to change the category of a product could be done by just assigning a new "ghost" entity to the product:

//Create a "ghost" entity with a static method

product.Category = Category.Ghost(3);

//Create a "ghost" entity with a regular constructor

product.Category = new Category(true){Id=3};

Moreover it would be nice if "ghost" entity could also been materialized, this means load the entity from the DB:

//Loading a product without including the relations

Product product = context.Product.Where(p => p.Id==3).First();

//Materializing the category relation = loading it

product.Category.Materialize();

re: Foreign Keys in the Entity Framework

Jason — Thu, 29 Oct 2009 03:06:25 GMT

Hi Alex,

Scenario 1 represents the greatest improvement among the scenarios presented. Please continue to strive for this level of simplicity.

I have to agree with Kristofer and Michael regarding scenario 3 though. This is another convoluted solution for something that has an obviously simple solution. I get your explanation of the scenario. I don't get why these steps couldn't be placed within the attach method itself. Doing so would increase the value of the EF because it would make the EF more intuitive. As it is, I look at it, scratch my head, and hope its a typo. Just like I did when reading about the use/necessity of EntityKeys. Simplicity is king.

This may seem like a goofy recommendation, but I think the EF team would benefit from hiring an information architect/interface designer (not a Comp Sci grad and not someone who bleeds MS). Someone who can bridge the gap between the users and the EF team. Just a suggestion.

I think the product shows huge potential and I want it to be successful. Mostly because I want to spend more time building apps and less time programming/struggling with the eccentricities of my tools.

Thanks for hearing me out...

- Jason