我看到了一些來自'可敬的'個人的演示，展示了實體框架的代碼優先功能。所有這些看起來都像令人垂涎的玩具！但有一件事讓我想起...什麼時候你會首先使用實體框架代碼
除了在開發時代碼優先場景會使我的項目受益嗎？
讓框架爲我構建數據庫對我來說似乎在項目的開發和測試（可移植性！）階段很棒，但當我更新實時項目時，我不希望發生這種情況。
知道什麼時候框架將要覆蓋我的數據庫並將我的靜態數據重新插入似乎是一個合理的想法（對於測試場景），但是我似乎已經將代碼構造到EF組件中了。
EF遷移是要清楚這一點？也許。任何人都有看法，爲什麼我應該先使用此代碼？
在我看來，自動生成數據庫僅用於開發和測試。將應用程序移至生產環境後，應確保關閉此功能。一旦決定部署新版本的應用程序，這一點尤其重要。
EF Migration可能會改變它我懷疑。我絕不會讓一些自動黑匣子觸碰我的生產數據。我們對VS數據庫工具的體驗已經非常糟糕，所以我們絕不讓他們直接使用真實數據 - 我們只讓他們爲我們生成腳本，我們精確測試這些腳本並在生產環境中手動執行這些腳本。有時甚至需要在臨時表中添加一些額外的遷移腳本。這正是我認爲應該與EF一起使用的方法。讓代碼首先在開發環境中創建一個新的數據庫，使用工具爲您創建針對舊數據庫的差異腳本，對其進行測試並部署它。
但最重要的是：生產數據庫上的任何升級或更改都應以備份開始，所以如果工具失敗，您可以隨時返回。
首先選擇代碼/數據庫優先/模型是基於how you like to develop application的方式和您的其他要求。
[new Migrations]（http://blogs.msdn.com/b/adonet/archive/2012/01/12/ef-4-3-beta-1-automatic-migrations-walkthrough.aspx?CommentPosted） = true＃commentmessage）（beta）東西看起來很有希望。它允許您通過自動或自定義更改進行升級/降級，併爲動手生產部署生成更改腳本（真棒！）。 –