當看到這個時，我也很震驚。估計絕大多數的人和我一樣，這些年來，一直不知道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）的方式。
1、 源代碼控制合並、沖突、代碼審審變得困難。當把整個模型存儲在一個xml文件時，我們收到了很多開發人員的反饋，模型上一個簡單的改動， 將導致xml中產生較大的差異。別一方面，開員人員得合並和重新審查源代碼。
2、 開發人員知道如何編寫和調試代碼。在一些簡單的項目中，設計器無可否認的帶來便利。然而，很多項目的需求卻超了出了設計器的能力范圍。遇到這種情況時，需要修改xml文件里的一些東西，但這對多數開發人員來說，這比修改代碼要艱難很多。
3、 根據環境自定義模型的能力。我們從客戶那里聽到這是一個很普遍的需求，比如，在程序運行時你需要指定架構或是表前綴的多租戶數據庫（Multi-tenant database）。也在可能會根據不同的數據庫提供商在運行時輕微調整你的模型。實現這些需求，使用操作基於xml文件的模型會異常艱難。另一方面，在代碼中使用條件邏輯來定義模型會很容易實現 。
4、基於代碼的模型不會重復。因為CLR類型同樣也能構建模型，以及有照顧一般配置（take care of common configration)的約定。 假設一個Blog實體擁有一個BlogId主鍵。在基於EDMX的模型中，在CLR類中會有一個BlogId屬性，一個xml BlogId屬性（外加列和映射）以及另外的一些xml內容來標識BlogId作為一個實體鍵。但在基於代碼的模型中，擁有一個CLR類型中的BlogId屬性就夠了。
5、在代碼中提供有用的錯誤信息更容易。我們都見過”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/