Foreign Keys in the Conceptual and Object Models

re: Foreign Keys in the Conceptual and Object Models

AG — Wed, 15 Dec 2010 22:39:09 GMT

I agree that FK's would have to be in the EF for performance reasons.

re: Foreign Keys in the Conceptual and Object Models

Aaron — Tue, 23 Jun 2009 16:37:54 GMT

I just want the ability to handle lookup tables. I don't care if you put foreign keys in the model so long as I can map an object to a foreign key.

For example, if I have a Customers table and a CustomerTypes table, I want the conceptual Customers object to have a CustomerType string that can be linked to the Description on the CustomerTypes table. This mapping should use the foreign key constraint to make sure that only valid CustomerType strings can be set.

re: Foreign Keys in the Conceptual and Object Models

John — Wed, 10 Jun 2009 18:16:38 GMT

I think FKs should be exposed and read/write. Linq to SQL had a reasonable approach. By not including it, it's true that you're enforcing the object-relational approach, but you're taking away an option for developers.

If it's that big of a deal, why not include the option to enable or disable FKs?

re: Foreign Keys in the Conceptual and Object Models

Jose Goncalves — Fri, 05 Jun 2009 14:15:34 GMT

KISS. Dont expose foreign keys in the Model because it is unnecessary and wrong. Dont take the kitchen sink approach please. There are other ways/alternatives to mess in with foreign keys if you really need to.

Foreign Keys in the Entity Framework

VS2010学习 — Thu, 04 Jun 2009 09:51:25 GMT

Background A number of months ago we asked whether Foreign Keys (FKs) in Conceptual and Object models

Better N-Tier Concurrency Management for the Entity Framework(Sum)

Web开发技术 — Sat, 30 May 2009 20:14:27 GMT

Better N-Tier Concurrency Management for the Entity Framework Posted in Technical at 11:03 am by Tony

re: Foreign Keys in the Conceptual and Object Models

Theo Koekemoer — Wed, 20 May 2009 08:52:31 GMT

Please allow FKs as both read-only and Setting the Values. Will make Life much better.

re: Foreign Keys in the Conceptual and Object Models

Terry — Tue, 19 May 2009 02:32:54 GMT

I would favor FKs as read-only properties. This avoid the "2 independent references to the same entity" issue while allowing some performance improvement when it is only necessary to reference the FK and not the whole entity.

re: Foreign Keys in the Conceptual and Object Models

Rick O'Shay — Wed, 08 Apr 2009 03:47:58 GMT

Everybody agrees the foreign key is unnecessary so the question boils down to convenience. The key is available through the object reference, so the argument about it being convenient is weak.

There are more downsides than you have listed. if you have two key values, which one does the data context believe? What happens when the related table uses a composite key?

Finally, it's this a mapping issue? Presumably we can map as many or as few columns as we want, however we want, so why not default to generating necessary values only (read: NOT adding both a reference and a redundant foreign key).

Finally, and this time I mean it, Hibernate and related technology have been using object reference only for almost a decade and nobody has complained. It's the right approach practically and theoretically

re: Foreign Keys in the Conceptual and Object Models

Jeroen Bernsen — Wed, 25 Mar 2009 22:17:16 GMT

I understand this feature is part of the impedance mismatch problem, but we really need this feature in some cases. E.g. in a web scenario a lot of times we have the ID value for the foreign key relationship but we don't want to fetch the object again, in these cases we would just want to set the foreign key property. Also in some N-Tier scenario's it can be very useful for us.

Thanks, Jeroen