假設FirstOrDefaultAsync在客戶端（Web 服務器）端運行而Where在主機（SQL 服務器）端運行是否正確，因此使用Where比使用FirstOrDefaultAsync 好得多？
如果答案是肯定的，那么我如何利用async的力量，因為我不能在Where之后呼叫FirstOrDefaultAsync？
在這種情況下，如何等待以最大程度地使用和優化我的資源？
uj5u.com熱心網友回復：
這里有兩個不同的東西
Where定義過濾器，稍后將用于生成 SQL 并且不執行查詢。FirstOrDefaultAsync定義過濾器并在 SQL Server 上執行查詢
所以你所有的假設都是不正確的。
uj5u.com熱心網友回復：
“我不能在 Where 之后呼叫 FirstOrDefaultAsync？”
var result = await context.Entities
.OrderBy(x => x.StartDate)
.FirstOrDefaultAsync(x => /* some condition */);
等于...
var result = await context.Entities
.Where(x => /* some condition */)
.OrderBy(x => x.StartDate)
.FirstOrDefaultAsync();
為什么Where在 ? 中使用 over 運算式FirstOrDefault？原因包括：
- 可讀性/組織。
- 條件查詢組合。
條件組合的示例：如果您有一個可選的 startDate 引數，您想要檢查和過濾（如果存在）：
嵌入式引數檢查：
var result = await context.Entities
.OrderBy(x => x.StartDate)
.FirstOrDefaultAsync(x => !startDate.HasValue || x.StartDate >= startDate.Value);
條件組成：
var query = context.Entities.AsQueryable();
if(startDate.HasValue)
query = query.Where(x => x.StartDate >= startDate.Value);
var results = await query
.OrderBy(x => x.StartDate)
.FirstOrDefaultAsync();
當您開始添加幾個可選條件時，嵌入的條件檢查可能會變得相當混亂，并且容易出錯，并且存在所有&&and||條件之間的括號“()”不匹配的風險。這最終意味著 EF 和由此產生的 SQL 需要進行更多的篩選作業。條件組合僅在需要時添加過濾運算式，從而在不使用條件時產生更簡單、更快的查詢。
需要考慮的關鍵點：
- 僅使用
First*帶有OrderBy*子句的方法以確保它們是可重復的。 - 僅使用
*OrDefault您明確期望沒有結果或默認值的方法。否則使用First/Single等并處理例外。 - 不要落入陷阱，認為可以
async使查詢更快并且應該默認使用。它實際上使查詢稍慢。（由于背景關系切換）
async是關于在特別昂貴的操作期間使諸如網路請求之類的事情更具回應性。如果某些事情要運行，比如說，超過 500 毫秒，async可以幫助確保 Web 服務器請求執行緒在運行時回應新請求。如果每個請求都委派給具有等待恢復點的作業執行緒，那么應該“進出”的快速命中最終平均需要更長的時間，并且除錯起來也更加混亂。它還可以用于特定操作會被大量潛在請求頻繁呼叫的情況，但在這種情況下，首先重要的是要確保它在針對該流量規模的硬體上運行。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/410547.html
標籤：