嵌套集合的DTO設計注意事項

鑑於我有一個模型，表示城市其中包含街道集合。嵌套集合的DTO設計注意事項

public class City { 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public IEnumerable<Street> Streets { get; } 
} 

public class Street { 
    public int Id { get; } 
    public string Name { get; } 
    public IEnumerable<Building> Buildings { get; } 
}

如果客戶有興趣所有城市（api/cities/all），我會回報他全額徵收，這將導致大規模的響應，這取決於數據集的大小。所以我首先想到的僅僅是返回街道ID裏面的街道集合。然而，這種感覺很尷尬，因爲儘管可能對進一步獲取街道很有用，但它們對於客戶端不具有任何有意義的價值（在視圖上填充ID的列表以顯示什麼是沒有意義的街道在城市，不是嗎？）。

我的下一個想法是收集完全溝街道，而是提供一個API端點去取城市的街道：

api/cities/3737/streets

這樣我可以獲取的完整列表街道，但是返回的數據並不包含街道所屬的任何信息。如果我現在的客戶想要顯示街道和城市，他必須進行2次API調用以獲取他需要的信息。

返回這些數據的常用方法是什麼？

來源

2015-01-09 xvdiff

事實是，沒有完全正確的方法來做到這一點。您需要決定什麼對您的應用程序性能有好處。一種應用程序的好處對另一個應用程序不利。 –

我將創建2個城市對象，一個只包含基本數據（如ID &名稱）和包含所有數據（包括完整街道平面圖）的cityDetail對象的城市對象。
根據你的情況，你可能會重複這種模式的建築物。
然後，您可以在您的列表調用中返回城市對象，並且只有在執行了獲取ID的情況下，您纔會返回cityDetail對象。

糟糕=>您的api很不協調，因爲您通過列表獲得的城市對象與您通過get獲得的城市對象不一樣。您可以創建2個資源：城市& cityDetail沒有List功能，城市沒有getByID功能，但仍然沒有像單個資源一樣可以預測的&。

該好=>性能明智&用法明智這通常是一個完美的匹配。你永遠不會顯示有街道的城市列表，所以城市對象就足夠了。在查看單個城市時，很可能要顯示包括街道在內的所有數據（或至少在該頁面上使用此數據），以便cityDetail對象也適合此處。
表現明智，有點明顯的是，獲取getAllMyCities電話的1百萬條街道是矯枉過正;）

來源

2015-01-09 07:29:03 Kristof

嵌套集合的DTO設計注意事項

回答

相關問題