代碼優先與模型/數據庫優先[關閉]

使用實體框架4.1代碼優先於模型/數據庫優先使用EDMX圖表有什麼優缺點？

我正在嘗試徹底理解使用EF 4.1構建數據訪問層的全部方法。 我正在使用Repository模式和IoC 。

我知道我可使用代碼優先方法：手動定義個人實體和上下文，並使用ModelBuilder來微調模式。

我還能夠建立EDMX圖並選擇使用T4模板生成相同POCO類的代碼生成步驟。

在這兩種狀況下，我最終都獲得了與ORM無關的POCO對象和源自DbContext上下文。

數據庫優先彷佛最吸引人，由於我能夠在企業管理器中設計數據庫，快速同步模型並使用設計器對其進行微調。

那麼這兩種方法有什麼區別？ 是僅僅關於VS2010與企業管理器的偏好？

---

#1樓

代碼優先彷佛是後起之秀。 我快速瀏覽了Ruby on Rails，它們的標準是代碼優先，具備數據庫遷移。

若是您正在構建MVC3應用程序，我相信Code首先具備如下優點：

• 簡單的屬性修飾 - 您可使用驗證，要求等屬性來裝飾字段，這對於EF建模來講很是尷尬
• 沒有奇怪的建模錯誤 - EF建模一般會出現奇怪的錯誤，例如當您嘗試重命名關聯屬性時，它須要匹配底層的元數據 - 很是不靈活。
• 合併並不尷尬 - 當使用像mercurial這樣的代碼版本控制工具時，合併.edmx文件是一件痛苦的事。 你是一個習慣於C＃的程序員，你正在合併一個.edmx。 代碼優先不是這樣。
• 首先對比代碼，你能夠徹底控制，而不須要處理全部隱藏的複雜性和未知數。
• 我建議您使用Package Manager命令行工具，甚至不使用圖形工具向scaffold視圖添加新控制器。
• 數據庫遷移 - 而後您還能夠啓用遷移。 這太強大了。 您能夠在代碼中更改模型，而後框架能夠跟蹤架構更改，所以您能夠無縫地部署升級，並自動升級架構版本（若是須要，能夠降級）。 （不肯定，但這可能也適用於模型優先）

更新

該問題還要求將代碼優先與EDMX模型/ db-first進行比較。 代碼優先也能夠用於這兩種方法：

• 模型優先 ： 首先編碼POCO（概念模型），而後生成數據庫（遷移）; 要麼
• Database-First ：給定現有數據庫， 手動編碼POCO以匹配。 （這裏的區別在於POCO不是自動生成的，而是給出現有的數據庫）。 您能夠接近自動，可是使用Generate POCO類和使用Entity Framework或Entity Framework 5 的現有數據庫的映射 - 如何從現有數據庫生成POCO類 。

---

#2樓

我首先使用EF數據庫，以便提供更多的靈活性和對數據庫配置的控制。

EF代碼優先和模型首先看起來很酷，並提供數據庫獨立性，可是在這樣作時它不容許您指定我認爲很是基本和常見的數據庫配置信息。 例如，表索引，安全元數據或具備包含多個列的主鍵。 我發現我想使用這些和其餘常見的數據庫功能，所以不管如何都必須直接進行一些數據庫配置。

我發如今DB中首先生成的默認POCO類很是乾淨，但缺乏很是有用的數據註釋屬性或映射到存儲過程。 我使用T4模板來克服其中一些限制。 T4模板很是棒，特別是與您本身的元數據和部分類結合使用時。

模型首先彷佛有很大的潛力，但在複雜的數據庫模式重構過程當中給了我不少錯誤。 不知道爲何。

---

#3樓

我認爲「編程實體框架」的做者Julie Lerman的這個簡單的「決策樹」應該有助於更有信心地作出決定：

更多信息在這裏 。

---

#4樓

從http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework引用相關部分

使用代碼優先設計實體框架的3個理由

1）減小臃腫，減小膨脹

使用現有數據庫生成.edmx模型文件和相關的代碼模型會產生大量自動生成的代碼。 你懇求永遠不要觸摸這些生成的文件，以避免你破壞某些東西，或者你的更改會被下一代覆蓋。 上下文和初始化程序也在這個混亂中被卡在一塊兒。 當您須要向生成的模型添加功能時，例如計算的只讀屬性，您須要擴展模型類。 這最終成爲幾乎全部模型的要求，並最終爲全部內容提供擴展。

使用代碼，您的手動編碼模型將成爲您的數據庫。 您正在構建的確切文件是生成數據庫設計的緣由。 沒有其餘文件，當您想要添加屬性或數據庫不須要了解的任何其餘內容時，無需建立類擴展。 只要遵循正確的語法，您就能夠將它們添加到同一個類中。 哎呀，若是須要，您甚至能夠生成一個Model.edmx文件來顯示您的代碼。

2）更好的控制

當您首先使用數據庫時，您將受到爲您的應用程序使用的模型生成的內容的擺佈。 偶爾命名約定是不合須要的。 有時，關係和聯想並非你想要的。 其餘時候，與延遲加載的非瞬態關係會對您的API響應形成嚴重破壞。

雖然幾乎總有一個解決方案可能會遇到模型生成問題，可是代碼首先會爲您提供完整且細粒度的控制。 您能夠在溫馨的業務對象中控制代碼模型和數據庫設計的各個方面。 您能夠精確指定關係，約束和關聯。 您能夠同時設置屬性字符限制和數據庫列大小。 您能夠指定要急切加載哪些相關集合，或者根本不進行序列化。 簡而言之，您負責更多的東西，但您能夠徹底控制您的應用程序設計。

3）數據庫版本控制

這是一個很大的問題。 版本控制數據庫很難，可是代碼優先和代碼優先遷移，它更有效。 由於您的數據庫模式徹底基於您的代碼模型，因此經過控制源代碼的版本，您能夠幫助對數據庫進行版本控制。 您負責控制上下文初始化，這能夠幫助您執行諸如播種固定業務數據之類的操做。 您還負責建立代碼首次遷移。

首次啓用遷移時，將生成配置類和初始遷移。 初始遷移是您當前的架構或基準v1.0。 從那時起，您將添加時間戳並帶有描述符標記的遷移，以幫助排序版本。 從包管理器調用add-migration時，將生成一個新的遷移文件，其中包含在UP（）和DOWN（）函數中自動更改代碼模型中的全部內容。 UP函數將更改應用於數據庫，DOWN函數在要回滾的事件中刪除相同的更改。 此外，您還能夠編輯這些遷移文件以添加其餘更改，例如新視圖，索引，存儲過程以及其餘任何更改。 它們將成爲數據庫模式的真正版本控制系統。

---

#5樓

恕我直言，我認爲全部的模型都有一個很好的地方，但我在模型第一種方法中遇到的問題是在許多大型企業中，DBA控制數據庫，你不能靈活地構建應用程序而不使用數據庫第一種方法。 我參與了許多項目，在部署時，他們須要徹底控制。

所以，儘管我贊成Code First，Model First，Database first的全部可能變體，但您必須考慮實際的生產環境。 所以，若是您的系統將成爲一個大型用戶羣應用程序，其中包含許多用戶而且DBA正在運行該節目，那麼您可能會認爲數據庫第一個選項只是個人意見。