在Web Api中更新實體的最佳實踐

Question

我正在研究從客戶要求的操作更新實體的最佳做法。 有幾種方法可以做到這一點，但似乎沒有最佳實踐。

1-從請求模型中獲取將通過反射更新的數據，並使用這些屬性更新實體。 但是不建議在Web API中使用反射。

2-將實體的所有數據發送到客戶端，並從請求中獲取其更新版本。 似乎造成不必要的流量。

3-獲取將要更新的數據，並檢查是否有其他條件更改獲取哪些數據。 它是如此基礎而不是通用，似乎如此不專業。

我所說的請求模型是實體模型的克隆。

Answer 1

首先，不要使用反射。 它像地獄一樣緩慢，並使您的代碼更加脆弱。

對於EF，通常有3種可能的解決方案：

1; 客戶端發送整個更新的實體，並且僅發送更新的實體。 在這種情況下，您只需要將實體附加到相應的實體集，然后將實體狀態標記為“已修改”。

2; 客戶端發送原始實體和更新的實體。 您附加原始文件並將當前值設置為更新實體。

3; 客戶端僅發送修改后的屬性，而不發送整個實體。 在這種情況下，您必須從數據庫查詢原始實體，並一一設置屬性，或者再次覆蓋currentvalue。

這三種方法的帶寬要求和查詢數量不同。

1; 如果我們以此為基准，則對帶寬有一個要求，即從客戶端向服務器發送一個實體，然后從服務器向數據庫發送一個實體。 這樣就可以進行1 db查詢（附加不需要查詢，因此只有保存更改部分才能啟動查詢）。

2; 它具有將兩個實體從客戶端發送到服務器的功能。 在這里，您必須將更少的數據從服務器發送到數據庫，因為更改的屬性是在設置currentvalue時計算的。 同樣，只有1個查詢（附加和設置currentvalue不會啟動查詢，因此只有保存更改部分才能創建查詢）。

3; 從客戶端到服務器以及從服務器到db的帶寬需求最少（兩次僅發送更改的屬性）。 但是，除了保存之外，還需要再執行一次查詢，因為在設置更改之前，您必須從數據庫查詢原始值。

我通常發現第一種方法是在其他兩種方法之間進行權衡。 它確實發送了比第三次更多的數據，但仍然少於第二次，並且僅啟動一個查詢以保存數據。 我也想最小化客戶端和服務器之間的流量，即使這意味着服務器和數據庫之間的流量更大。 客戶端（至少對我而言）通常是移動的，因此不保證帶寬，也不保證電池壽命。 服務器和數據庫“更緊密”，它們沒有這些限制。 但是，當然這對於您的應用程序可能有所不同。