0

When I first started to learning EF Code-First, I just assumed that we would include in our models all the properties we want to have in the resulting tables - including int or string foreign keys. We would also include navigation properties for lazy loading.

One of my hunches with EF is that we (supposedly) can create models strictly as pure OOP objects without caring about database relationships. This means we can remove those foreign key properties and instead have/keep virtual navigation properties which would reflect the actual relationship we intend - and it'd be up to the framework to automatically create the right foreign key constraints.

We probably need to use Fluent API for more specifics like delete cascade and which of the two columns gets the (auto-generated) foreign key.

Has anybody actually tried not including the foreign key in the model?

Mickael Caruso
  • 8,721
  • 11
  • 40
  • 72
  • You apparently did not learn much of EF, since this is laid out pretty clearly in most books on the subject. What you're talking about is called "independent associations" and is not recommended because it's more difficult to work with, and is not as flexible. – Erik Funkenbusch Feb 02 '14 at 21:39
  • I've only read tutorials and followed them. None of them addressed the issue of independent vs. fk associations. They just pretty much said "include the fk property AND the navigation property". – Mickael Caruso Feb 02 '14 at 21:41

0 Answers0