WCF數據對象最佳實踐

我正在從Web服務遷移到WCF，而不是試圖讓舊的代碼在WCF中工作，我只是要重建服務。作爲這個過程的一部分，我還沒有想出提供易於使用的服務並支持未來變化的最佳設計。WCF數據對象最佳實踐

我的服務遵循以下模式;我實際上有比這更多的方法，所以重複代碼是一個問題。

<ServiceContract()> 
Public Interface IPublicApis 

    <OperationContract(AsyncPattern:=False)> 
    Function RetrieveQueryDataA(ByVal req As RequestA) As ResponseA 

    <OperationContract(AsyncPattern:=False)> 
    Function RetrieveQueryDataB(ByVal req As RequestB) As ResponseB 

    <OperationContract(AsyncPattern:=False)> 
    Function RetrieveQueryDataC(ByVal req As RequestC) As ResponseC 

End Interface

跟着this意見，我首先創建了Request和Response對象的模式。然後，我使用SvcUtil創建了結果類，以便我確信對象可以被其他語言消耗，並且客戶端會發現模式易於使用（不引用其他模式）。但是，因爲請求和響應具有相似的數據，所以我想使用接口和繼承，這樣我就不會實現相同代碼的多個版本。

我曾想過在獨立的類庫中使用接口和繼承編寫我自己的類的版本，並在那裏實現所有的日誌記錄，安全性，數據檢索邏輯。在每個操作中，我只需將RequestA轉換爲我的InternalRequestA並調用InternalRequestA的處理函數，該函數將返回一個InternalResponseA。然後我會將其轉換回ResponseA併發送給客戶端。

這個想法是瘋了嗎？！？我在尋找另一種利用內部繼承的解決方案時遇到問題，但仍然爲支持未來更新的客戶端提供乾淨的架構。

來源

2011-03-24 Zach Green

使用WCF數據契約創建的契約通常會生成相對直接的模式，這些模式具有高度的互操作性。我相信這是WCF設計的指導原則之一。但是，這種互操作性與消息本身有關，而不是其他系統可能從中產生的對象。消息如何轉換到/從另一端的對象完全取決於其他系統。

對於使用數據約定對象的繼承，我們沒有真正的問題。因此，考慮到你明確控制了模式（即它們沒有在外部指定），並且可以很好地利用WCF的內置數據合同功能，所以我很難看到你將獲得額外的複雜性和工作量的好處暗示在你提出的方法中。

在我看來，與處理消息相關的邏輯應該完全獨立於消息本身。

來源

2011-03-25 01:08:26

我接受了你的答案，因爲對大多數人來說它是正確的。在我的情況下，我想我會繼續進行對象轉換，因爲它允許我只需要執行一次執行的開銷任務，而且必須執行每種類型的請求。 – 2011-03-28 17:09:19

WCF數據對象最佳實踐

回答

相關問題