a、支持對關系型數據的批量更新。 什麽意思就不用細說了吧，在這之前，很多人噴糞EF，就是說他的更新效率太低，如果要實現批量更新，特別插入時，需要借助sql語句或是第三方工具類。相信這是很多人期待的功能；
b、支持唯壹約束。它允許妳在實體內除主鍵外額外標識壹個鍵，將他們用作外鍵。
B、行為(Behavior)改變
在EF6和前期的版本中，頂層API就有很多不直觀的行為，雖然EF7盡可能是保持頂層API的相同，但仍去掉了壹些限制並添加了壹些我們期待的行為。什麽意思呢？這聽起來有點迷糊，舉個例子來說明吧，以前的查詢，雖然Linq給我們帶來了很大方便，但限制多呀，整個Linq查詢翻譯成壹條單獨的sql查詢，Linq查詢中只能包含EF能翻譯成sql的語句或方法；還有就是sql的生成，有時生成了很復雜、效率不高，且不是我們希望的sql語句。EF7改變這種情況，可以返回多結果集，sql評估工作也不是在數據庫端來做了，變更到客戶端。這樣就為生成sql提供了很大的靈活性。如果還有點暈，沒關系，先有個印象就行。
C、變得更加簡單、靈活
直接使用壹個例子來說明吧。我們想通過EF的元數據來獲取Blog實體被映射到數據庫中的哪壹張表。在這之前，我們的代碼會是這樣:
在EF7中會代碼會是這樣：
using (var db = new BloggingContext())
{
var tableName = db.Model.GetEntityType(typeof(Blog)).Relational().Table;
}
D、去掉了壹些特性
a、每類型映射多個實體集（MEST)。這個特性，估計用的人很少，正是因為使用的人少，所以才去掉。它是什麽意思呢？就是壹個類型對應數據庫中的多張表，例如：表Product 和 RetriedProduct都映射到Product類。如果妳還有這樣的需求，使用繼承是更好的選擇。
b、非常復雜的類型映射。在EF6.x中，可能在壹個繼承映射中組合了TPH,TPT和TPC。EF7不再支持這種復雜的映射了，它要求妳的CLR 類型盡量跟表結構保持壹至。至於為什麽，我相同不少人到現在都還沒有弄明白什麽是TPH,TPT,TPC,那更說不上靈活運行了，這也是導致EF6.x MetadataWorkspace異常復雜的主要原因。
c、去掉edmx建模。這可能會讓很多人失望，因為它曾經給我們帶來多麽美好的回憶。但它有很多的不足，比較壹些復雜的需求，不適應ddd分層設計，不符合現在流行的POCO等。最主要的是，有更好的選擇code-based建模，這就是我們常說的code-first。 可能妳會有疑問，怎麽code-first和edmx是平級概念，它不是跟db-first、model-first平級的嗎？ 沒錯，它是跟edmx平級的，更詳細的解釋請查看我的另壹篇博客Code First is a bad name，這些年我們對Code First的理解都錯了 ！很震驚吧？
d、去掉ObjectContext API。它陪EF壹起成長，到EF4.1時才被DbContext弄到幕後.不過DbContext只是它的外觀模式，底層仍然是使用的它。有時需要使用壹些高級的功能時，我們還想辦法把它找出來。去掉它並不意味著它以前的壹些功能不能用了。EF7重寫了底層，把之前壹定需要它才能使用的api包含在了DbContext中，並且調用更加清晰，簡單。
e、去掉了延遲加載。 這功能相信大家不陌生，它壹直被當成EF的壹大特點，但現在，它將要從EF7中去掉。我不確定最終的版本微軟會不會把它請回來，因為這壹點存在很大的爭論。無論是我們這些開發人員，還是EF的開發團隊。我個人是支持去掉的。壹，不是所有的應用都需要延遲加加載；二、不少的EF使用者對它沒有深入的去了解，經常會有人問，為什麽會出現"無法完成該操作，因為 DbContext 已釋放"這樣的問題。這說明這個功能反而給壹部份使用者帶來了困惑。
這些變化並不是最終的，也許文中說的，會發生改變。當然這裏也不可能列出所有的變化點，畢竟EF7還在處於開發過程中。總之，它是壹個革命性的版本，以至於有人在爭論應該叫他EF7呢，還是EF1。
E、對非關系型數據庫的支持，文章開頭部分已經有提到，這裏就不多說了。
四、EF7的開發計劃
相信，很多人和我壹樣，去年就開始期待EF7的發布。壹年多長長的等待，可是它還沒有出來，到底要什麽時候呢？微軟的計劃是2016年，所以大家得耐心等待。不過，有個好消息是，它是開源的，最新的源代碼在github上，如果妳想了解更多的細節，可以到下面的地址（/aspnet/EntityFramework）去克隆或是下載源代碼。下面是EF的開發計劃表