儘管脫離了 .NET Core發佈循環，但是EF Core正在開發其3.0路線圖。除此之外，還對原來的Entity Framework進行了一些重要的變更。
儘管脫離了 .NET Core發佈循環，但是EF Core正在開發其3.0路線圖。除此之外，還對原來的Entity Framework進行了一些重要的變更。
基於 .NET Core 3的Entity Framework 6.3
首先，Entity Framework已經結束了。從功能方面，已經沒有新的東西要加入到Entity Framework 6.x系列，而且不太可能出現Entity Framework 7了。
即便如此，Entity Framework還沒有被完全遺忘。Microsoft已經認識到將遺留數據庫代碼從EF 6轉移到EF Core並非一件易事，這也是採用 .NET Core的一大障礙。
目前的計劃是提供運行在 .NET Core上的Entity Framework的旁支版本。這需要全新的特定於數據庫的提供程序。另外，有些功能（比如SQL Server的空間數據）將不被支持。
本文中的其餘內容適用於EF Core。
更多服務器端的查詢
將LINQ查詢轉換爲對應的SQL查詢通常是比較困難的，甚至是不可能的。許多QRM只能在轉換失敗時拋出一個運行時異常來解決這個問題，但是EF Core做了更多的嘗試。當不能完全理解LINQ查詢時，它會將其部分轉換爲SQL，之後在客戶端執行剩下的操作。儘管這可能會導致性能不好，很多開發人員更喜歡這種方案，而不是查詢直接失敗。
Diego B Vega寫道，
在EF Core 3.0中，我們計劃對LINQ實施和測試的方法進行重大變更。目標是讓它變得更加健壯（比如說，避免在補丁發佈版本中破壞查詢），讓更多表達式準確轉換爲SQL，在更多情況下生成有效的查詢，防止沒有檢測到效率低下的查詢的情況發生。
NoSQL支持
很長一段時間，人們都希望ORM可以無縫地處理SQL和NoSQL數據庫。儘管Microsoft一開始宣佈它將作爲 EF Core 2.1路線圖的一部分，但是公司目前仍然在嘗試引入這一功能。新的計劃是在EF Core 3.0中提供對Cosmo DB的支持。
C# 8.0支持
EF Core 3.0將成爲第一個支持C# 8的版本。這主要代表着API在更新之後可以包含 [可爲空的引用類型]和異步流。關於如何做到這一點仍待確定，因爲EF Core 3.0的一大目標是保留 .NET Standard 2.0庫。這可能會與C# 8的一些功能背道而馳。
因爲 .NET Framework不會支持C# 8的所有新功能，所以Entity Framework 6.3也不太見得可以支持C# 8。
更好地支持視圖
不像Entity Framework，EF Core不能在數據庫中爲視圖產生查詢類型。查詢類型僅適用於可以從數據庫中讀取但不能寫入的實體。通常，這應該是查詢視圖、存儲過程或表值函數的結果。
代碼生成器的這一疏忽預期將在EF Core 3.0中修復。
多對多關係
要在EF Core中表示多對多關係，目前你需要能表示映射表的“連接實體”。有了“屬性包實體”功能之後，EF Core離擺脫這種需求又更近了一步。
該特性支持實體將數據存儲在索引屬性中，而不是常規屬性中，並且能夠使用相同. NET類的實例(可能簡單到Dictionary<string, object>)來表示相同EF核心模型中的不同實體類型。
請注意，Entity Framework已經在不需要連接實體的情況下支持多對多關係。
不在EF Core 3.0路線圖上的功能
由於預算有限，並不是所有的需求都能加入到路線圖中來。以下這些特性雖然沒有加入其中，但也很有必要提一下。
存儲過程
EF Core 3.0 timeframe中不會提供對存儲過程的一流支持。可以使用查詢類型和原始SQL的變通方案。
每個類型繼承的表
當表很寬，有很多列的時候，一項解決此問題的技術是每個類型繼承的表（Table Per Type inheritance）。使用該模型之後，每行都會被識別爲多個子類型之一。每個子類型都有自己的表，表中有這個子類型特有的列。只有所有子類型都有的列纔會保留在原始表中。
目前Entity Framework支持每個類型繼承的表這一功能，但是EF Core並不支持。儘管從2015年開始，大家都非常希望這個功能可以實現，但它也是很有爭議的。對於有些人來說會將它視爲反模式，因爲如果不恰當使用，它就會損傷性能。
另外一些人認爲每個類型繼承的表可以提升性能，因爲連接原始和子類型表的成本會比處理一個很寬的表來的小。另外，現實世界的數據庫已經使用了這種模式，EF Core需要和這些現有的數據庫保持一致。
還有，EF Core中不需要每個類型繼承的表，是因爲Entity Framework中已經存在了，而且EF計劃會移植到 .NET Core中來。人們對此的反駁是，我們可能既需要每個類型繼承的表，也需要EF-Core獨有的功能。
Visual Studio Designer
Diego B Vega寫道：
我們瞭解設計可能是我們的一些客戶使用EF Core的一個重要功能，但我們並沒有看到很多反饋表示它比我們待辦事項中的其他功能更加重要。我們很有興趣瞭解你是否嘗試代碼優先開發，瞭解你是否知道有工具可以將現有的數據庫反向工程到EF Core模型。
更新插入
更新插入是有條件地插入或更新一條記錄的功能，這被視爲ORM的第二層功能。儘管沒有必要，但擁有它也是很好的，因爲它可以減少往返訪問數據庫的次數，並簡化代碼。然而，它目前並不適合EF Core模型。部分原因是它實現的方式在各個數據庫之間存在太大的差異。有些具備明確但獨特的語法。有些利用MERGE語句，但由於它不是原子性可能會產生問題。還有Jet/MS-Access完全不接受更新插入，但是可以用多個查詢來模擬。
更新插入目前在Github上的Merge/Upsert/AddOrUpdate支持思路中討論。
GraphQL
實現GraphQL是非常困難的。這個查詢語言非常複雜，如果沒有框架或者庫來支持它，甚至是部分實現也很難做到。
幾年以前Microsoft確實曾推出過使用EF Core的GraphQL，但從來沒有公開發布過。儘管還有很多GraphQL的設計問題需要得到解決，但他們還是希望能在未來真正實現這一功能。