EF 模型優先還是程式碼優先方法？
我知道這個問題已經被問過很多次了，因為我已經閱讀了很多關於利弊等主題的文章，但我仍然無法決定哪種方法適合我。我對網路程式非常陌生，並且來自 SQL DB 管理員/報告寫作背景。我決定嘗試建立自己的網站，將來可能會有 30 -40 張桌子。
我已經研究過這兩種方法，並且我確實喜歡實體模型方法，只是因為我喜歡設計器的簡單性，而且我喜歡在我面前看到整個模型，它在一張快照中顯示了整體畫面。此外，我不是一個強大的程序員，我對它使用 DbContext 生成器模板生成 POCO 並在類之間進行所有連結的方式印象深刻。
然而，雖然我喜歡模型優先方法，但我覺得有一些缺點，我不確定它們是否是實際的缺點，或者我只是對模型優先方法和程式碼優先方法不夠了解，因為我仍然非常對此很陌生。
我對使用 Model First 方法猶豫不決的原因是：
主要是因為我很難找到關於使用 MVC 3 的模型優先方法的教程。我發現使用 DbContext 的最佳教程是 Julie Lerman 的，但她沒有涵蓋對於使用數據註釋和製作其他重要的伙伴類重新生成 POCO 時不會失去的更改。大多數與 MVC 3 相關的教程似乎都使用程式碼優先方法。大多數人說這是因為導師不想專注於EF，而是在tuts中展示更多的MVC。我個人認為這是因為微軟支持 Code First 方法而不是其他方法 :)
如果創建夥伴類是一種很好的做法，為什麼我找不到很多針對 MVC 3 的教程？Buddy Classes 是視圖模型的另一個名稱嗎？為什麼我找不到 Microsoft 提供的任何教程來展示這些與 MVC 3 一起使用的伙伴/視圖模型？
我試圖在 2 個表之間建立基本的 1 對 1 關係。在模型中，您必須將每個表的標識鍵設置為相同的欄位，而不是在其中一個表中使用 FK，當您有 3 個或更多表通過 1 對 1 關係相互連結時，這可能會有點混亂. 在程式碼中，解決此問題的一種方法是使用模型建構器並手動設置它。我認為在 MF 中，您可以通過進入我根本不喜歡做的 XML 來改變關係。
更多關於程式碼優先問題的支持/幫助
我對使用 Code First 方法猶豫不決的原因是：
-我是新手編碼員。
-我發現隨著項目的擴展，跟踪表格和關係變得非常困難。
- 沒有模型圖，我不得不說我真的很喜歡這個想法。
-通過配置類將實體映射到數據庫我覺得不可能:)。
-更新表將需要更改程式碼和數據庫。在模型中，只有一個模型更改會自動更新數據庫和程式碼，如果你使用夥伴類，你可能也必須更新這些。
此外，現在我看到人們在某種程度上將 Code First 和 Database first 方法結合起來，因為您不讓 Code First 生成數據庫，而是手動創建數據庫並使用 Code First API 到 EF 來獲取它。
我的頭腦在思考所有的選擇、缺點和利弊。我只想繼續創建我的網站，而不是考慮採用哪種方法。任何人都可以根據我所說的和/或他們認為將來會成為主流的方法，給我一些關於他們認為最好的方法的見解嗎？
非常感謝戴夫
這個問題太長了。下次你應該把你的問題分解成多個單獨的問題。
程式碼優先 x 模型優先 x 數據庫優先
您是數據庫專家，因此對您來說最好的方法是增量數據庫優先方法，您可以在 DB（或 VS 數據庫工具）中定義內容並從數據庫更新模型。這將使您對數據庫有很大的控制權，並允許您以增量方式建構應用程序和數據庫。為什麼我認為你會喜歡它：
- 您之前做過 SQL DB Admin - 您可能知道一些關於 DB 的知識以及如何設計它們以獲得性能 - EF 不會為您做任何事情。EF 不會為您創建索引等。
- 30-40張桌子意味著您不會一次建構模型。您將從小型模型開始並不斷發展它。一旦您開始在數據庫中進行更改或添加初始化數據，您將不希望失去這些更改和數據。程式碼優先只允許刪除整個數據庫並從頭開始重新創建它。模型優先允許逐步建構數據庫，但您需要Entity Designer Database Generation Power pack和 VS 2010 Premium 或 Ultimate ($5.000-$10.000)。
更多關於DB first、Model first 和 Code first 之間的區別。另一個答案描述了程式碼優先和使用設計器之間的區別。
DbContext API + 數據庫優先 + Fluent 映射
我認為這是最難的方式。您將首先定義數據庫，然後使用 DbContext fluent API 或數據註釋來定義映射。這需要很好地理解 EF 以及映射背後的所有原則 + 理解 DbContext API 中使用的預設約定。它將為您提供對映射的良好而明確的控制，但這是最需要做的工作。這絕對是最難走的路。也不應該使用它，因為 DbContext API 主要是為程式碼優先方法創建的。
DbContext API x ObjectContext API
開始使用 EDMX（實體設計器）後，您可以選擇使用 DbContext Generator T4 模板或 POCO Generator T4 模板。決定權在你手中——你可以使用 DbContext API（第一個模板）或 ObjectContext API（第二個模板），它的文件記錄要好得多，你還可以使用兩本好書：
我對 ObjectContext API 的了解都來自這些書籍、作者的部落格和實踐 + Reflector。
DbContext API 目前沒有任何書籍。您可以查看一些主要網站以獲取有關它的資訊：
我對 DbContext API 的了解都來自這些部落格和實踐 + Reflector。
即使您首先使用程式碼，您仍然可以使用類圖來視覺化您的類圖（它與 EDMX 不同，但足以了解全域）。
在 Stack Overflow 或MSDN 論壇上進行搜尋將為您提供使用這兩種 API 時遇到的大多數問題的答案。
MVC 3
在 MVC 3 中使用實體框架並沒有什麼特別之處。用於數據驗證註釋的伙伴類被認為是不好的做法。夥伴類是用作應用於實體的元數據持有者的單獨類。視圖模型是用於在控制器和視圖之間傳輸數據的類。視圖模型應該針對每個視圖使用自己的驗證註釋，因為在使用相同的實體類型時，您通常需要在應用程序的不同螢幕中進行不同的驗證 - 例如，編輯和插入螢幕可能有不同的驗證要求。
儘管事實上它不被認為是好的做法，但向實體添加驗證是可能的 - 您可以手動為每個實體創建夥伴類，也可以嘗試修改 T4 模板以直接為您生成註釋（這很難） .
一對一關係
是的，EF 只需要在主鍵之上創建一對一的關係。原因是 EF 不支持唯一鍵/約束。沒有辦法解決這個問題，在數據庫中使用唯一鍵不會改變它。