最想要的Entity Framework功能
Entity Framework 團隊已經建立了一個用戶之聲論壇，以便用戶提交功能請求并對它們進行投票。我們聚焦當前得票率最高的 7 個功能請求，同時給出了你現在可用的潛在替代方法。
這些是至今為止請求頻率最高的一些功能——
1、改進的 SQL 語句生成（狀態=已啟動）
該請求是——
我親眼目睹，具有 4 或 5 個子查詢的簡單的 select 語句卻產生了將近 5000 行的 SQL 語句，然而等效的手寫 SQL 語句僅有 15 行。
對此微軟已經取得了一些進展。他們的回復是——
對 Entity Framework 核心庫的更新將包含在 .NET 4.5 中，其中將會包括一些對于 SQL 語句生成的改進。然而并非評論中所提到的所有情形都將予以處理。
替代方法： 沒有真正的替代方法，除非停止使用 Entity Framework。
2、批量創建更新刪除（CUD）支持 （狀態=評估中）
對于業務線（LOB，即 Line of Business）應用程序而言，批量創建/更新/刪除是一關鍵功能，而在大多數對象關系映射（ORM）工具中大概都沒有此功能。像 DBase 和 PowerBuilder 等一些早期編程語言在幾十年前已有此種能力。一些人甚至提出，對象關系映射（ORM）工具不適用于大容量事務，而更適合于在線交易處理（OLTP）及非批處理操作。
替代方法——
- 對 Entity Framework 的這個擴展提供了批量更新和刪除的能力（但不能批量插入）。
- 不要使用 Entity Framework 進行大容量事務處理——請自行編寫 SQL 語句。事實上，這可能是一處避免使用對象關系映射工具的理想位置。
3、Entity Framework 支持二級緩存（Second Level Cache）（狀態=評估中）
雖然這是 NHibernate 所支持的功能，但是對于 Entity Framework 卻不是現成的。
替代方法——Julie Lerman 在她的文章“用 Entity Framework 和 AppFabric 實現二級緩存”中演示了如何使用 Windows Server AppFabric 實現二級緩存。
4、實體設計器：為擁有 200 個以上實體的使用場景進行加速和優化
替代方法：一旦模型中的實體數目達到 50 至 100 時就把該模型拆解開來。這篇以往的博文仍可作為為什么支持此功能不僅是個技術難題而且對于用戶體驗也是挑戰的相關解釋。不知道是否微軟將會考慮此功能，即使此功能已投票勝出。
5、多數據庫支持（狀態=評估中）
由于模型目前始終被映射到單一數據庫，因此該功能還不可用。
替代方法—— 需要使用同義詞、并合并兩個模型，從而騙過 Entity Framework 以便支持橫跨多個數據庫。
6、設計器支持使用 GUID 作為實體鍵值（Entity Key） ——與其說這是個功能，不如說是個錯誤，當使用設計器為某個 GUID 列添加 StoreGeneratedPattern 屬性時并不會更新數據模型的存儲部分。當創建新記錄時，這會導致 GUID 列獲得“000..” 的錯誤值。
替代方法—— 正如此文所解釋的那樣，請在 .edmx 文件中手工添加 StoreGeneratedPattern 屬性。
7、按 Rails 遷移的方式進行數據庫架構（schema）遷移 （隨著 Code-First 遷移完成即將與 Entity Framework 4.3 一起到來）
此功能目前與 Entity Framework 4.3 版本在一起處于測試階段。有關此功能的更多細節參閱 MSDN 博客。
替代方法—— 使用數據庫項目來創建升級腳本。一旦 Code-First 新版發布，則重建新的數據庫架構（schema），并將其導入一個新的數據庫項目中，然后將其部署到舊的數據庫上。
還有許多由不同用戶提出的其他有趣的功能想法，你一定要投票或者提交自己的想法，以便讓 Entity Framework 團隊知道對你而言什么功能是最重要的！
查看英文原文：Most-Wanted Features in Entity Framework
譯者：高翌翔，基于 .NET 平臺進行 Web 應用程序設計、開發，關注敏捷開發和架構設計，及各種提高代碼可維護性的最佳實踐。