Code First is a bad name，這些年咱們對Code First的理解都錯了 ！很震驚吧？

　　當看到這個時，我也很震驚。估計絕大多數的人和我同樣，這些年來，一直不知道Code Fisrt的真實意義。下面是一篇講述此狀況的譯文，歡迎圍觀，如有翻譯不當的地方，請指正，謝謝。若是被驚到了，請點贊！，不滿意就拍磚吧。E文好的，可直接看下邊的原文。

原文地址：http://blogs.msdn.com/b/adonet/archive/2014/10/21/ef7-what-does-code-first-only-really-mean.aspx

轉載請註明出處：http://www.cnblogs.com/VolcanoCloud/p/4483708.html

　　進入主題以前，我先說一下，我聽來的。聽說微軟最開始想使用的是 Code Only，後來因爲他們的營銷團隊不知道是爲了跟Database First 、Model First 對應仍是怎麼的，就出現瞭如今的 Code First.

EF7-"Code First only"的真實意思究竟是什麼？

　　不久前，咱們在博客中寫到，咱們計劃將EF7打形成一個輕量級的、可擴展的版本。它將是一個全新的平臺和數據存儲（data stores)。咱們在北美技術大會（TechEd North America)關於EF的會議中，一樣有說起EF7的計劃。

　　在EF7以前，存儲（譯註：這裏當動詞用）模型有兩種方式，一種是基於XML的EDMX文件格式，一種是基於代碼。從EF7開始，咱們將再也不支持EDMX格式，轉而只支持單一的基於代碼風格的存儲。對於移除對基於XML的EDMX這事，引發不少人的擔心，他們中間，多部分人是源於對「EF7 將只支持Code First「真正含義的誤解。

Code First 是一個糟糕的名字

　　在EF4.1以前，咱們只支持Database First和Model First兩種工做方式，它他均使用EF設計器提供的方框和直線來表示存儲在基於xml格式的.edmx文件中的模型。Database First 從一個已存在的數據庫逆向生成一個模型，Model First從EF設計器中建立的模型生成數據庫。

　　在EF4.1中咱們引入了Code First. 不幸的是，不少人依據它的名字認爲，它是在代碼定義模型，而後從模型生在數據庫， 事實上，Code First 一樣也能用於一個已經存在的數據庫或者是生成一個新的數據庫。有工具能夠支持逆向一個已存在的數據庫生成Code First模型，這個工具最初是包含是EF工具集中，後來在EF6.1中被集成到生成EDMX模型的嚮導中。

　　換句話來講，Code First 不是相對 Database First 和Dodel First的第三種方式，而是一種能夠替代EDMX文件格式的方案。從概念上講，Code First 同時支持Database First和Model First工做方式。

　　這的確讓人感到混亂，咱們取錯了名字。 或許叫它「基於代碼建模（code-base modeling）」會更清晰些。

 

是否是使用基於代碼建模（code-base modeling）這個名字就更好的呢？

　　很明顯，咱們得維護兩種不一樣的建模方式。除此以外，還有別的緣由讓咱們選擇在EF7中只支持基於代碼建模（code-base modeling）的方式。

 

　　　　一、 源代碼控制合併、衝突、代碼審審變得困難。當把整個模型存儲在一個xml文件時，咱們收到了不少開發人員的反饋，模型上一個簡單的改動，　　　　 將致使xml中產生較大的差別。別一方面，開員人員得合併和從新審查源代碼。

 

　　　　二、 開發人員知道如何編寫和調試代碼。在一些簡單的項目中，設計器無能否認的帶來便利。然而，不少項目的需求卻超了出了設計器的能力範圍。遇到這種狀況時，須要修改xml文件裏的一些東西，但這對多數開發人員來講，這比修改代碼要艱難不少。

 

　　　　三、 根據環境自定義模型的能力。咱們從客戶那裏聽到這是一個很廣泛的需求，好比，在程序運行時你須要指定架構或是表前綴的多租戶數據庫（Multi-tenant database）。也在可能會根據不一樣的數據庫提供商在運行時輕微調整你的模型。實現這些需求，使用操做基於xml文件的模型會異常艱難。另外一方面，在代碼中使用條件邏輯來定義模型會很容易實現 。

 

 　　　　四、基於代碼的模型不會重複。由於CLR類型一樣也能構建模型，以及有照顧通常配置（take care of common configration)的約定。 假設一個Blog實體擁有一個BlogId主鍵。在基於EDMX的模型中，在CLR類中會有一個BlogId屬性，一個xml BlogId屬性（外加列和映射）以及另外的一些xml內容來標識BlogId做爲一個實體鍵。但在基於代碼的模型中，擁有一個CLR類型中的BlogId屬性就夠了。

 

　　　　五、在代碼中提供有用的錯誤信息更容易。咱們都見過」Error 3002: Problem in mapping fragmets starting at line 46...(3002:映射段問題，始於文件46行處...）的錯誤。這個來自基於EDMX模型報告應該被改進。可是在基於代碼的模型中拋出一個配置錯誤的異常會很容易。

　　咱們可能已注意到，在EF6.x版本，常常會從代碼優先管道（Code-First pipeline)中得不到有用的錯誤信息，這是由於它是創建在爲EDMX模型設計的基礎設施上。在EF7中，將不會存在這樣的狀況了。

 

　　還有一很重要的功能，可能會被EDMX實現，但這隻能在基於代碼的模型了。

　　數據庫遷移（Migrations) ,它容許你從基於代碼的模型建立數據庫，並隨着模型的改變而演進。對於EDMX模型，你能夠生成一個與當模型匹配的SQL腳原本建立數據庫，可是沒有辦法生成一個包含模型變化的腳本，將模型變化應用於已存在的數據庫。

 

那麼，EF7會帶來什麼呢？

　　在EF7中，全部的模型均經過代碼來表示了。有工具能夠從一個已存在數據庫逆向生成一個模型（像在EF6.x中那樣），你也能夠先經過代構建一個模型，而後使用數據庫遷移(migrations）技術生成數據庫（當模型發生變化時獲得更新）。

　　可能已經注意到，咱們在EF7中已經改進了數據庫遷移（migrations）技術，解決不少人在團隊環境中使用它時所遇到的問題。

 

怎麼解決...

　　咱們已經討論了全部能想到的，選擇只支持基於代碼建模（code-based modeling)是一個正解選擇的緣由。但隨之而來的問題產生了。

 

怎麼可視化模型？

　　EF設計器全是關於模型可視化，同時在EF6.x中，咱們有能力爲基於代碼的模型產生一個只讀的可視化模型（使用EF工具集）.在EF7中咱們一樣認爲這是一個好的方法。可視化是絕對有價值的，特別是當你有大量的相聯的類時。

　　Roslyn（微軟推出的一種編譯器）的到來，咱們也能夠看到擁有一個可讀可寫的、基於代碼模型的計設器。很顯然，這不是立馬就實現（多是永遠），由於這是一個巨大的工做。但他是咱們努力的目標。

 

怎麼解決「從數據庫更新模型」場景？

　　「從數據庫更新模型」是這樣的一個過程，它容許你當即拉入一個附加的數據庫對象（或是修改一個已存在數據庫對象）到你的EDMX模型。不幸的是，這個實現，不是一個好的特性。由於你一般會所以喪失了自義定模型的能力，不得不手工去修改xml文件來調整模型。

　　對於Code First 你能夠經過從新運行逆向工程進程，從新生成你的模型，在一些基本的場景中，這種方法表現得很好。可是你關心的是，新生成的代碼會覆蓋你在模型中自定義部分。不少的自定義，若是不經過修改搭建的代碼，將很難適用。

　　咱們在EF7中第一步是，提供一個跟EF6.x中第一次發行的逆向工具同樣的工具。在不用重寫以前自定義的代碼的狀況下實現模型的增量更新上面，咱們有很多的想法。 從支持簡單的添加場景到使用Roslyn編譯器修改已存在代碼。 咱們正在思考這些想法，目前尚未確切的計劃。

 

怎麼解決已經存在的模型？

　　咱們不掩飾EF7相對EF6.x所發生的巨大改變，雖然咱們保持原有的概念和頂層API,可是底層實現發生了巨大的變化。基於這個緣由，咱們不建議立馬就將已存在模型轉移到EF7中來，咱們將繼續保持開發EF6.x一段時間。

　　

全部的人都須要改變嗎？

　　咱們不自欺人，不可能讓全部的人都改變，咱們知道有一些人對EF設計器和EDMX的喜好超過了基於代碼建模。

　　與此同時，咱們必須平衡時間和資源，咱們會分享咱們認識最好的特性和功能來幫助開發人員編寫一個成功的應用。 這並非咱們輕率，由於對於實體框架的長期發展和用戶來講，這是最好的選擇。最終的目標是提供一個更快速的、更簡單的使用棧，以及減小支持高需求的成本。咱們一直朝着這樣方向努力。

 

　　翻譯中，確定有不少不當的地方，懇請你的指正，同時，請點擊下邊的推薦來支持。謝謝！但願你有收穫。

 

　　下面是另外一篇MSDN的博客，是中文的，你們也能夠去看看，原文地址：https://msdn.microsoft.com/zh-cn/magazine/dn890367.aspx。我摘抄一段我認爲對你們有幫助的片斷以下：

放棄 EDMX，但繼續實行數據庫優先

　　實體框架當前使用兩種方法來描述模型。一種使用設計器中的 EDMX；另外一種涉及類，即代碼優先 API 使用的 DbContext 和映射。若是您使用的是 EDMX 和設計器，則運行時 EF 會在 EDMX 後從 XML 中建立內存中模型。若是您選擇代碼優先路徑，則 EF 會經過讀取類（即您提供的 DbContext 和映射）來建立相同的內存中模型。從那之後 EF 的工做方式是相同的，不管您如何描述模型。請注意，經過 EDMX/設計器工做流，您還能夠獲取 POCO 類和 DbContext 供您在代碼中使用。可是因爲 EDMX 的存在，所以不會使用它們來建立該內存中模型。當您閱讀下文時，理解很重要：EF7 將不支持基於設計器的 EDMX 模型。它沒法在運行時讀取 EDMX XML 來建立內存中模型。它將只使用代碼優先工做流。

　　當團隊發表有關這方面的博文時，引發了不少開發人員的恐慌。部分緣由是不少開發人員還沒有意識到能夠將數據庫反向工程到 POCO 類、DbContext 和映射。換言之，您能夠從數據庫開始來獲取代碼優先模型。能夠經過 2011 年初首次發佈的 EF Power Tools Beta 來實現這一目的。該工具受 EF6.1 設計器支持，且確定也會受 EF7 支持。我已屢次提到「代碼優先」這一名稱有一些迷惑性和誤導性。最初它稱爲「僅限代碼」，後來這一名稱改成「代碼優先」以完美匹配「數據庫優先」和「模型優先」。

　　所以，要從現有數據庫開始，您無需設計器或 EDMX。

　　可是，若是您擁有現有 EDMX 模型，而且不想失去使用設計器的能力，會怎樣呢？有一些第三方設計器支持實體框架，例如早已支持 EF 代碼優先的 LLBLGen Pro Designer (bit.ly/11OLlN2) 以及 Devart Entity Developer (bit.ly/1yHWbB2)。查找可能提供支持 EF7 的設計器的工具以及其餘可能的軟件。

還要記住另外一個方法：堅持使用 EF6！

 

 

實體框架交流QQ羣:  458326058，歡迎有興趣的朋友加入一塊兒交流

謝謝你們的持續關注，個人博客地址：http://www.cnblogs.com/VolcanoCloud/