Is it really necessary to create a property that indicates the foreign-key of a One-To-Many relationship?

Navigation
1

I would like to know if the information I found after searching, which briefly is in the link below, proceeds:

link

Question:

In a hypothetical situation, if we have the Car class and the Tag class, where Car has a tag > and Tag can have several Cars (One-to-Many), EntityFramework forces me to create a ' in> Car , or otherwise I would have to load the entire Tag at the time of an inclusion / change of a Car if I do not want to use a TagId field?

Reason for question:

Even in the links where I found this information, they point out that this practice hurts OO good practices. Is there a better solution for these cases?

    
asked by anonymous 17.07.2015 / 21:55

1 answer

1

Does EntityFramework require me to create a MarcaId field in the car object?

Yes. It is the default of the Framework.

In addition, you would have to add a navigation property (as below) to stay entirely within the default: 

public virtual Marca Marca { get; set; }

I would have to load the entire object Marca at the time of an inclusion / change of a Carro ?

No. The load of Marca is lazy by default. It is made in the navigation property I mentioned above.

I do not agree that the Entity Framework standard hurts OO practices.

... if I do not want to use a MarcaId field?

If you do not want to use it, it will not work, simply because you are not following the pattern of the Framework. MarcaId is mapped to database, so it must exist as property in class Carro .

About the tutorial

It has several inaccuracies. I do not recommend basing it.

    
17.07.2015 / 21:58
How to use inverted function in this case of jquery? Query in dbgrid paradox 7 using edit in delphi