WCF設計 - 一個請求和響應對象或多個？

Question

您應該爲每種方法制作一個請求/響應對象，還是每個服務應該有一個？

如果我在所有方法中使用它，我的服務請求對象只有5個不同的東西，因爲我幾乎所有的方法都使用相同的輸入。

響應對象只有一個字典，一個bool，一個表示一個ID的int和一個字符串值。我不確定我在創建一堆單獨的對象時看到了這一點，它們都具有相同的內容，而不僅僅是使用一個對象。

什麼被認爲是最佳實踐？

Answer 1

我會建議每個方法只包含該方法提供和返回的請求和響應信息。原因在於，從客戶端wsdl生成代理服務器代碼時，調用客戶端對該方法的期望是什麼會更清楚。

Answer 2

IMO沒有一個放之四海而皆準的所有答案 - 這取決於

如果你有過線的兩端「控制」（即自己的.NET客戶端是WCF的只有消費者服務），那麼共享類型是有意義的（即在客戶端和服務器上重複使用相同的實體程序集）。如果你這樣做，那麼在項目中的所有服務之間共享一組共享實體將節省重新發明輪子的時間（例如對於結果代碼，分頁信息，額外的自定義上下文信息等）。您也可以使用生成的服務引用，或直接在您的客戶端中使用ClientBase>共享的ServiceContract接口。在這種情況下，只要序列化/反序列化正確，您並不真正'關心'線路上的數據。

但是，如果您的WCF服務還有其他非.NET客戶，那麼還有其他一些考慮因素。

DataContractSerializer爲每個方法（通常是Method和MethodResponse）創建一個請求和響應模式，並在兩個方法上都包含方法簽名（包括參數變量名稱）。它將取決於客戶端WSDL映射技術，以確定請求和響應中的公共實體是否會「滾動」到可重用實體中，或每次是否創建新實體。

使用DCS，沒有「壓力」將不相關的字段/參數包裝到一個類中 - 例如，您的留言簽名可以

public DoSomethingResult DoSomething(int parameter1, SomeEntity parameter2, string parameter3); 

你也可以考慮MessageContracts。這「迫使」你更多地考慮數據在線路中的外觀，請求和響應包含在包裝實體中。 IMO MessageContracts在EAI場景中運行良好（例如，如果您有BizTalk使用者），因爲您建議的常見響應消息可以在多個服務調用中重複使用。

HTH

Answer 3

我與尼克Ryan的答案達成一致。看看我前段時間寫的博客詳情http://www.link-intersystems.com/blog/2012/01/12/pros-and-cons-of-service-layer-designs/