在Entity Framework代碼中，爲了映射導航屬性，我還需要映射外鍵列

假設我有一個Trade對象，它有一個外鍵給一個Counterparty對象。我想在我的Trade對象中有一個類型爲Counterparty的導航屬性 - 我是否也需要在Trade對象中擁有外鍵列（CounterpartyId）？我的實驗似乎表明我是這樣做的。我嘗試在導航欄中添加[ForeignKey（「CounterpartyId」]，但如果沒有CounterpartyId列，它也不起作用。在Entity Framework代碼中，爲了映射導航屬性，我還需要映射外鍵列

來源

2017-07-09 Shane

不，顯式FK屬性不是強制性的。 "Counterparty_Id"shadow屬性和列名在相應的數據庫表。

在這種情況下，有沒有辦法來配置與數據註解的陰影屬性/列名，因此，如果你想要做的，你需要流利的配置與MapKey（而不是HasForeignKey當你有明確的財產）：

modelBuilder.Entity<Trade>() 
    .HasRequired(e => e.Counterparty) // or HasOptional if you want nullable column 
    .WithMany() // or WithMany(e => e.Trades) if you have inverse collection navigation property 
    .Map(m => m.MapKey("CounterpartyId"));

請注意，流暢配置必須反映剛好您的模型導航/ FK屬性。例如，你以後你決定ConterpartyId屬性添加到您的Trade對象時，你應該用Map

.HasForegnKey(e => e.CounterpartyId)

來源

2017-07-09 10:41:30

所以屬性配置只能映射的什麼都能用流利的API使用權被映射的子集取代？這有點令人遺憾，流利的API有點冗長。是否可以將屬性映射與流暢配置混合？ – Shane

正確。流暢的API是一點冗贅的，但IMO很清楚。有了屬性（尤其是關係），你永遠不知道你到底在做什麼 - 例如'ForegnKey'可以應用於導航屬性或FK屬性。而字符串取決於你在哪裏應用它。不是談論具有完全違反直覺的屬性的複合PK/FK。 –

非常感謝您的回答。我已經發布了另一個問題在https://stackoverflow.com/questions/45007072/object-added-through-collection-navigation-property-not-saved-when-parent-is-det你不會知道答案那個你會呢？ – Shane

在Entity Framework代碼中，爲了映射導航屬性，我還需要映射外鍵列

回答

相關問題