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

Question

我正在研究從客戶端調用的操作更新實體的最佳實踐。有幾種方法可以做到這一點，但它們都不是最佳實踐。

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

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

3-獲取將要更新的數據，並檢查它們是否有條件以獲取哪些數據被更改。它非常基本，不通用，看起來非常不專業。

我提到的請求模型是實體模型的克隆。

Answer 1

首先，不要使用反射。它太慢了，使你的代碼變得更加脆弱。

說到EF，通常有3種可能的解決方案：

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

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

3;客戶端只發送修改的屬性，而不是整個實體。在這種情況下，您必須從db中查詢原始實體並逐個設置屬性，或者再次覆蓋當前值。

這三種方法在帶寬要求和查詢次數上有所不同。

1;如果我們以此爲基準，它就有一個帶寬要求，即將一個實體從客戶端發送到服務器，然後將這一個實體從服務器發送到數據庫。這使得1分貝查詢altogehter（附加不需要查詢，所以只有保存更改部分啓動查詢）。

2;這具有從客戶端向服務器發送兩個實體的帶寬。在這裏你必須從服務器發送更少的數據到數據庫，因爲當你設置當前值時，已更改的屬性會被計算。再次，只有1個查詢（附加和設置currentvalues不啓動查詢，所以只有保存更改部分創建一個查詢）。

3;這對客戶端到服務器以及從服務器到數據庫的帶寬要求最低（兩次只發送更改的屬性）。但是，除了保存之外，這確實需要多一個查詢，因爲在設置更改之前，您必須從數據庫中查詢原始值。

我通常發現第一種方法是另外兩種方法之間的良好折衷。它確實發送了比第三個更多的數據，但仍然少於第二個，並且它僅啓動一個用於保存數據的查詢。我也希望儘量減少客戶端和服務器之間的流量，即使這意味着服務器和數據庫之間的流量更多。客戶（至少對我來說）通常是移動的，所以沒有保證的帶寬，沒有保證的電池壽命。服務器和數據庫非常「接近」，他們沒有這些限制。但是，對於您的應用程序，這當然會有所不同。