一步步学习EF Core(3.EF Core2.0路线图)
前言
這幾天一直在研究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 預覽版本中的全局查詢過濾器已經解決了這一點
簡單的命令攔截提供了在發送到數據庫之前/之后讀取/寫入命令的簡單方法。
更多的數據庫支持
Redis
其他非關系型數據庫
Azure Table Storage
平臺
通用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）?- 有助于改進和調試應用程序的診斷信息,使他變得更容易訪問。
下面是取得了一些進展但有無法按時完成風險的內容：
自包含類型映射（＃7434）?- 使擴展類型映射器更容易處理其他類型。
數據播種（＃629）?- 允許在模型中指定數據庫的初始數據，并自動填充到數據庫中。
原來考慮加入,但沒有進展，基本上要推遲的內容：
用于非實體類型的原始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,后期還要加入更多的數據庫函數.大大增強了代碼可讀性和效率
相關文章：
一步步學習EF Core(1.DBFirst)
一步步學習EF Core(2.事務與日志)
原文地址：http://www.cnblogs.com/GuZhenYin/p/6873397.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的一步步学习EF Core(3.EF Core2.0路线图)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 行动力决定了一个人的成败，有想法，就去做
- 下一篇： Build Tour 2017 中国站北