Moja klasa Order posiada:W jakiej scenariusze muszę klucze obce i właściwości nawigacyjnych w ramach jednostki
public int CustomerId { get; set; }
public Customer Customer { get; set; }
Czy naprawdę muszę zarówno właściwości sprawiają relację działa?
Nie używam rozłączonych podmiotów, używam kodu pierwsze podejście.
Według książki Julii Lerman: Programming Entity Framework: DbContext, różnica polega na trudności z aktualizacją właściwości nawigacji. Na stronie 85 zasugerowała: "Jeśli jest jedna rzecz, którą możesz zrobić, aby ułatwić sobie życie w scenariuszach N-poziomowych, to ujawnić obce właściwości dla relacji w twoim modelu." Książka zawiera próbki dla obu scenariuszy.
Powód jest taki, że włączenie cechy klucza obcego mówi Entity Framework, aby używało klucza obcego, co jest prostsze niż użycie tak zwanego Independent Association, gdy trzeba zaktualizować relację, tj. Zmienić zamówienie z jednego klienta na inny w twoim przykładzie. W przypadku obcego powiązania kluczy wszystko, co musisz zrobić, to zmienić CustomerId. Bez klucza obcego CustomerId potrzebujesz więcej kroków. Niezależne skojarzenie korzysta z ObjectStateManager, który jest wyjaśniony. Code First: Independent associations vs. Foreign key associations? ObjectStateManager jest złożony i nie jest nawet odsłonięty z interfejsu API DbContext.
możliwy duplikat [Code First: Independent association vs. Foreign key association?] (Http://stackoverflow.com/questions/5281974/code-first-independent-associations-vs-foreign-key-associations) –
@ Gert Przeczytałem artykuł, który dołączyłeś. Wciąż nie wiem, czy potrzebuję obu. Kiedy mam odniesienie do jednostki, powinienem mieć również klucz obcy ... tak, żeby się po prostu Powtarzał ... – Elisabeth
Myślę, że informacja mówi, że absolutnie nie potrzebujesz 'CustomerId', ale lepiej (chociaż to zależy od ciebie) . Chciałem również połączyć cię z terminologią, która leży u podstaw twojego pytania, i zbiorem źródeł, które ją omawiają. –