這幾天一直在研究EF Core的官方文檔,暫時沒有發現什么比較新的和EF6.x差距比較大的東西.
不過我倒是發現了EF Core的路線圖更新了,下面我們就來看看
今天我們來看看最新的EF Core 2.0路線圖
E文好的移步:https://github.com/aspnet/EntityFramework/wiki/Roadmap#ef-core-20
嗯,我就直接翻譯了,翻譯的不好請各位大神原諒..
以下是EF Core的路線圖。請注意，功能計划可能會更改。
這跟任何項目一樣，很難准確地預測什么時候會確定。
即使如此，我們也認為盡可能公開和透明地對我們的計划非常重要，
這樣我們的用戶就可以獲得正確的期望並相應地制定自己的計划。
1.時間表
EF Core的更新計划與.NET Core和ASP.NET Core時間表同步,如下:
| 發布版本 | 發布季度 |
|---|---|
| 2.0- preview1 | 2017年第2季度 |
| 2.0- preview2 | 2017年第2季度 |
| 2.0 | 2017年第3季度 |
| 2.1 | 2017年第4季度 |
值得注意的一點是,在ASP.NET Core的路線圖中,全新的SignalR將在ASP.NET Core2.1版本發布
2.積壓的內容
因為EF Core是一個新的代碼庫，所以在Entity Framework 6.x中存在一個功能並不意味着會在EF Core中實現。
具體區別請移步:比較EF Core和EF6.x
我們提供了我們認為重要但還沒實施功能列表。僅供參考
3.關鍵的ORM功能
下面是微軟開發團隊認為需要的東西，微軟爸爸覺得..嗯..EF Core是可以向所有人推薦的EF版本。
但是在實現下面這些功能之前，雖然EF Core對於許多應用場景來說是一個有效的選擇（特別是在.NET Core的平台上，因為EF6.x不起作用..(懵比臉)..），
但是對於許多應用來說，缺少下面這些功能將使EF6.x是目前更好的選擇。
嗯..下面就是微軟爸爸覺得需要,但是還在研發 或者斟酌的東西:
3.1Query(查詢)
- 改進的Linq翻譯將使更多的查詢成功執行，使得更多的邏輯在數據庫（而不是內存中）中進行查詢，從而減少不必要的數據庫訪問。(這一項已經在2.0預覽版本完成了很多.)
- 延遲加載功能。
- 對於不在模型中的原始SQL語句查詢,允許使用原始SQL語句查詢來填充不在模型中的類型（通常用於非規范化的視圖模型數據）。
3.2數據庫圖形化管理
- 用於DBFirst的Visual Studio向導，允許您在從現有數據庫創建模型時,可視化地配置連接，選擇表等。
- 從數據庫更新模型允許以前從數據庫逆向工程的模型將隨着您對架構的更改而刷新。
3.3Modelling(實體模型)
- 復數/值類型是不具有主鍵的類型，用於表示實體類型上的一組屬性。這通過EF Core 2.0中支持的所有類型和表解決。其中一部分已經在預覽1完成了
- 存儲過程映射,允許EF使用存儲過程來保存對數據庫的更改（
FromSql已經提供了對使用存儲過程進行查詢的良好支持）。 - 改進的視圖映射,允許EF自動從數據庫逆向工程視圖或使用遷移維護它們(DBFirst)。
4.高優先級的功能
-
實體模型
- 更靈活的屬性映射，如構造函數參數，get / set方法，屬性包等。
- 簡單的類型轉換，如string => xml。
- 多對多關系沒有連接實體。可以與連接實體建立多對多關系。
- 關系數據庫的替代繼承映射模式，例如每種類型的表（TPT）和每個具體類型TPC的表。
- 空間數據類型，如SQL Server的
geography＆geometry。 - 可視化模型圖以查看CoreFirst的模型圖形。
-
CRUD
- 初始化數據允許數據庫在遷移過程中自動填充初始數據。
- ETag式並發令牌支持提供了統一的編碼模式，用於管理與模型配置無關的並發性。
- 貪婪加載,允許在查詢實體時始終檢索默認的相關數據集。
- 過濾加載,允許加載相關實體的一個子集。EF Core 2.0 預覽版本中的全局查詢過濾器已經解決了這一點
- 簡單的命令攔截提供了在發送到數據庫之前/之后讀取/寫入命令的簡單方法。
-
更多的數據庫支持
- Azure Table Storage
- Redis
- 其他非關系型數據庫
-
平台
- 通用Windows平台（UWP）目前適用於本地開發，但是與.NET Native工具鏈中的.NET Native工具鏈存在問題，EF和.NET Native團隊正在努力解決。
- Xamarin在使用EF core還未完全測試.
5.EF Core 2.0（還開發中...）
預覽1版本已完成的主要功能：
- 簡化服務和提供商的架構（＃7457） - 允許EF Core及其提供商以更簡單和更有效的方式使用DI。(依賴注入~)
- Group Join改進（＃2546） - 此工作改進了為Group和Join所生成的SQL語句。
- 改進的LINQ翻譯（來自於GitHub上的各種問題） - 允許更多的查詢成功執行，更多的邏輯在數據庫中執行（而不是內存中），從而減少不必要地從數據庫查詢數據。
- EF.Functions.Like（）（＃2850） - 允許將通配符的字符串匹配轉換為SQL或在內存中進行匹配。
- 擁有的實體和表分割（以啟用復雜類型和/或值對象模式）（＃246） - 允許映射類型不具有自己的身份，但始終依賴於其他對象，並將它們映射到與其父對象相同的表。
- 全局查詢過濾器（＃5774） - 允許為實體類型配置垂直過濾器。然后，此過濾器將適用於所有查詢，包括貪婪加載（即
Include()）。 - 上下文池（＃6923） - 通過使
DbContext實例可以重用而不是始終從頭開始創建，從而提高性能。(重要!!!重要!!!重要!!!) - 手動編譯查詢（＃8449） - 允許查詢表達式與代理相關聯，從而可以只編譯一次但執行多次，從而不會導致增加高速緩存鍵計算和高速緩存查找的成本。
- 將SQLite提供程序移動到SQLitePCL.raw（Microsoft.Data.Sqlite＃21） - 這為Microsoft.Data.Sqlite提供了一個更強大的解決方案，用於在不同平台上分發本機SQLite二進制文件。
- IEntityTypeConfiguration（＃2805） - 允許一個實體的Fluent API配置到一個類中。
下面是期望完成的其他功能：
- 每個模型＃7166只有一個提供商） - 顯着增加了供應商如何與模型進行交互，並簡化了慣例，注釋和流暢的API如何與不同的提供商合作。
- 綜合測試和診斷（＃218，＃7217等）
- 應用程序洞察集成（＃8272） - 有助於改進和調試應用程序的診斷信息,使他變得更容易訪問。
下面是取得了一些進展但有無法按時完成風險的內容：
原來考慮加入,但沒有進展，基本上要推遲的內容：
- 用於非實體類型的原始SQL查詢（＃1862） - 使用不在模型中的類型執行具有臨時映射的查詢。
- Azure搜索集成 - 允許您在查詢數據時使用Azure搜索中的搜索索引。在數據更新操作期間透明地同步索引數據。
- 從數據庫更新模型（＃831） - 允許您逐漸更新以前從數據庫反向設計的模型，並更改了對數據庫模式所做的更改。這允許您更新模型以匹配當前模式，而不會丟失在反向設計后手動對模型進行的任何更改。
- 生命周期掛鈎（＃626） - 包括創建實體（
ObjectMaterialized從EF6.x），數據庫命令攔截，連接打開時運行附加命令的事件。 - 簡單的日志記錄API（＃1199） - 我們想要一個簡單的方法來記錄正在執行的SQL（就像
Database.Log從EF6.x）。我們還需要一種簡單的方法來查看正在記錄的內容。 - GroupBy翻譯＃2341 - 允許使用GroupBy（）運算符翻譯LINQ查詢，該項目用於匯總要使用GROUP BY轉換為SQL查詢的函數。
原來考慮加入,但是至今沒有加入計划的任務：
- 基於ODBC的提供程序（＃7432） - 這將允許為具有ODBC提供程序的數據庫（但可能沒有特定於數據庫的ADO.NET提供程序）創建一個EF Core提供程序。
其實從路線圖可以看出來,微軟爸爸的整個構想是相當好的.
而且聽取了很多社區中好的意見和建議(每個功能后面的"#一串數字",就是Github的Issues)
嗯,從EF4.0用EF一直到現在,也算是死忠粉了.最后說一下我個人比較關注的幾個功能.
1.上下文池（＃6923）,這個太TM及時了..淚流滿面啊..想想每次被人吐槽的初始化產生的性能損耗..想想..竟然還需要預熱啟動..,是不是有種撥開雲霧見太陽的感覺..
2.EF.Functions.Like（）（＃2850） - 這個目前是只加入了like,后期還要加入更多的數據庫函數.大大增強了代碼可讀性和效率