服務堆棧的DTO模式真的有用嗎？

Question

嗯，我過去曾經使用過ServiceStack ORMLite，現在試着用我的手來處理ServiceStack RESTful DTO模式。我過去曾經使用過WCF/Web API，對於使用不同方法的服務來說，這是一種自然的範例，您只需在需要時就發起RPC調用。然而，一邊唸叨Servicestack的DTO模式，它主打的說法：

當你和一個遠程接口的工作，如遠程門面 （388），每次調用它是昂貴的。因此，您需要減少呼叫數量，這意味着您需要在每次呼叫時傳輸更多的 數據。一種方法是使用大量參數。 但是，這對程序來說通常很尷尬 - 實際上，對於只返回單個 值的Java等語言而言，這通常是不可能的。

解決的辦法是創建一個數據傳輸對象，該數據傳輸對象可以容納呼叫的所有 數據。它需要可序列化以穿過 連接。在DTO和任何域對象之間，通常在服務器端使用匯編器來傳輸數據到 。

參數本身迴避了很多問題要問我：

1. 這是否意味着當與產品對象有關係的頁面加載，然後我們就從產品的錶帶上的所有數據，並保持周圍對於任何重複使用（潛在的重複使用）？
2. 如果一個電話得到所有結果是很多數據？我是否可以不爭辯說，有時當一個調用中的「GetAll」帶來大量不必要的數據，然後在需要時返回服務器是一個更好的主意？
3. 另外，聽起來這個模式假設客戶端開發人員會利用它作爲DTO模式。該服務將被調用一次，並且返回的數據將長時間保存在內存中以供進一步重用。如果我是一個糟糕的開發人員，並且完全忽視這樣一個事實，即該服務被設計用於大量重用，並且每次需要任何數據時都會致電服務。那不就是兩刃劍嗎？

Answer 1

的Data Transfer Object pattern不是唯一的模式從，它也採用了相關Remote Facade和Service Gateway模式，這前面的回答describes benefits it gains by leveraging clean DTOs ServiceStack的基於消息的服務效益和文檔列出Advantages of message-based Services。

這是否意味着當與產品對象有關係的頁面加載，然後我們只是把從產品表

無粗粒度的接口中的所有數據是不是把整個產品的數據集和緩存在客戶端。您只會返回那些適用於該上下文的數據，因此如果您需要有關產品的信息，那麼您將在查看產品時返回對客戶端有用的產品和相關元數據，例如，類別/供應商信息，以防止客戶端執行多個服務調用以獲取他們需要的內容，從而減少延遲，減少需要維護/記錄/學習的API表面面積，使同一服務對於不同的客戶端使用案例更加可重用使用支持多個客戶端的單個緩存條目，而不太可能的後端服務需要在UI更改時重寫 - 而不是客戶特定的RPC調用。

如果一個調用得到所有結果是大量的數據？

當您只需要總結搜索結果時，不要停止整個數據集。優化搜索以僅返回需要在搜索結果中顯示的數據。查看單個數據集時，您可以獲取與產品相關的元數據。

如果我是一個糟糕的開發人員，並且完全忽視這樣的事實，即該服務被設計用於大量重複使用，並且每次需要任何數據時都會調用服務。那不就是兩刃劍嗎？

API消費者不太可能在他們現有的服務返回他們需要的數據時尋找不同的API來調用。擁有更少的粗粒度API調用自然會使自己的調用更少，更容易緩存，即使對於不知道如何構建高效的併發API調用的幼稚開發人員，也可以減少延遲。