在WCF服務中創建私有數據成員

在WCF服務中創建私有數據成員是否是一個好主意，如果這是一種很好的做法，那麼當我們初始化這些成員變量時，因爲客戶端只調用服務的方法。在WCF服務中創建私有數據成員

2012-02-20 Abdul Samad

僅將數據合約用作DTO，並將其擴展到處理數據的代碼中。

事情是這樣的：

[DataContract] 
public class WCFDataClass 
{ 
    [DataMember] 
    public String Foo { get; set; } 
} 

// Your class, used for internal processing 
class MyWCFDataClass : WCFDataClass 
{ 
    public String MyFoo { get; set; } 

    public String DoFoo() 
    { 
     return this.Foo + this.MyFoo; 
    } 
}

來源

2012-02-20 14:58:03 CodeCaster

如果您有任何的互操作性的興趣，我相信dont't它一般是一個很好的做法。

首先創建合同（操作合同，消息合同，數據合同等），以明確的方式指定哪些是支持的，哪些不支持。它明確地公開指定這些事情。當你開始宣佈私人成員參與公共合同時，很快就會變得非常混亂。程序員在你發現後面的事情之後會產生問題。

您可能試圖將邏輯封裝在數據合同中，這不是數據合同的目的。正如@CodeCaster所建議的那樣，這種操作應該在數據契約類之外進行。即使簡單的事情，如構造函數填充默認值可能會有問題。這種邏輯也應該在DataContract類之外執行。

此外，當您聲明私有成員爲[DataMember]時，您依賴於數據協定序列化程序的非標準實現細節 - 事實上它可以讀取/寫入不是公有的成員 - 即DataConstractSerializer（至少在.NET平臺上）可以做你在自己的代碼中無法做到的事情。你依靠'魔術'。雖然這個'魔術'有助於DataConstractSerializer提供驚人的性能，但我認爲您不應該依賴於它的實現細節。例如，您會發現DataContract類無法與Silverlight應用程序共享，因爲在該平臺上，DataConstractSerializer無法讀取/寫入非公共成員。

然而，就像所有'慣例'一樣，你必須考慮你的情況。如果互操作性和可維護性不是要求，則上述大部分內容不相關，可以忽略。 :)

來源

2012-02-20 22:25:53

在WCF服務中創建私有數據成員

回答

相關問題