實體框架不提供 DeleteAsync 或 AddAsync。 為什么？

Question

我只是注意到 EF（此處使用版本 5）不提供DeleteAsync() / AddAsync() 。 我還注意到像這樣的項目：

https://github.com/zzzprojects/EntityFramework-Plus

事后提供DeleteAsync() 。 為什么 EF 不提供DeleteAsync() ？ 只是好奇。

附錄：正如 EF-Plus 的維護者所指出的，我提到的“DeleteAsync”風格與 EF 的“Delete”/“DeleteAsync”有些不同，因為前者對查詢目標元素進行操作，這些元素將在db/db-server，而 EF 的 Delete 操作在調用 'Delete()'之前已經檢索到的元素。 盡管這些方法的簽名存在差異，但我的問題引起的最初關注仍然是其優點。

Answer 1

免責聲明：我是Entity Framework Plus的所有者

Add && Remove from Entity Framework 和Delete from my library 之間存在巨大差異。

添加/刪除

Add 方法只會將實體添加到 ChangeTracker，而 Remove 方法只會將 ChangeTracker 中的 EntityState 更改為“Deleted”。

正如@Ivan 指定的那樣，在您調用SaveChanges或SaveChangesAsync之前， Remove不會直接在數據庫中保存更改

刪除

此功能從數據庫中刪除行，而無需在上下文中加載實體。

調用此方法可能需要相當長的時間，具體取決於將在數據庫中刪除的行數。

因此，在這里提供DeleteAsync方法是有意義的。

正如@Matt 指定的那樣，該庫當前使用Task.Run而不是真正的異步，最終將被修復。

Answer 2

在觀看了 MattJohnson 提供的非常有啟發性的材料並使用反射探討了 Delete 的實現之后，我推測沒有提供 DeleteAsync() 背后的原因是 delete 導致數據庫在單個工作單元內被更改-實例生命周期。

如果有人通過 Task.Run() 提供了“DeleteAsync()”操作（也就是沒有真正的異步實現），這將有效地通過反模式誘導幻覺，因為開發人員會使用這種 API 認為他們享受好處'true-async' 但實際上他們不會- 他們只會遭受不必要的開銷 ala 'await Task.Run(() => context.Foo.Delete(x))' 而不會享受任何好處。

TL；DR：關於為什么 EF 的人不提供“DeleteAsync()”/“AddAsync()”的底線解釋是“異步方法不應該說謊”（正如 MattJohnson 指出的）和“DeleteAsync()”鑒於在撰寫本文時 EF 的當前實現，/'AddAsync()' 肯定會撒謊。

Answer 3

我認為所有答案的要點是， Remove()方法不是一個耗時的操作，而它只改變跟蹤器中的一個簡單狀態，而其他對應物（例如Find()需要 ping 數據庫，這將是一個時間-消費過程。
另一方面，像AddAsync()這樣的方法是按照它的評論說的：

此方法是異步的，僅允許特殊值生成器（例如“Microsoft.EntityFrameworkCore.Metadata.SqlServerValueGenerationStrategy.SequenceHiLo”使用的值生成器）異步訪問數據庫。 對於所有其他情況，應使用非異步方法。