WCF服務客戶端訪問內部構件

（使用NH實現）與類中的一個說測試，定義爲

[DataContract] 
public class Test

定義爲

internal Test() 
    { 

    } 

    public Test(int param1, IList<Int32> param2, int param3) 
    { 
     this.Param1 = param1; 
     this.Param2 = param2; 
     this.Param3 = param3; 
    }

兩個構造

現在，我希望我的客戶端應用程序只使用params訪問第二個構造函數，而不是使用內部嘗試隱藏的默認構造函數。

但實際發生的事情恰恰相反。在客戶端應用程序中，我只能看到內部構造函數。

有什麼想法？

來源

2009-11-06 iniki

你是如何創建客戶端代理類？ – 2009-11-06 12:46:02

我承擔了我的WCF服務作爲Windows服務，並在我的客戶端asp.net應用程序中添加了服務引用。 – iniki 2009-11-06 12:48:08

在WCF中，當你添加一個服務引用，你會得到一個客戶端代理 - 但對於數據，只有數據（和沒有行爲）是反序列化 - 這是一個儲存和運輸的唯一的事情XML模式。

您的客戶端代理無法發現並使用任何其他構造函數，您的數據合同對象上的任何其他方法 - 僅限數據部分通過網絡傳輸。

此外，標準DataContractSerializer（默認情況下由WCF使用）在從接收到的消息中反序列化數據時甚至不會調用任何構造函數 - 它只會分配足夠大的內存塊用於數據，然後將這些位移入適當的存儲位置。任何構造函數都被繞過（這也解釋了爲什麼DataContractSerializer不需要在其數據類上使用公共參數較少的構造函數 - 就像XmlSerializer一樣）。

來源

2009-11-06 13:01:28

謝謝您花時間解釋:-) – iniki 2009-11-06 13:09:24

默認情況下，WCF遵循面向服務的核心原則之一：

服務共享契約，而非類

這意味着，當你在Visual服務引用Studio，VS詢問有關服務元數據的服務。此合約以WSDL和XSD表示，並根據合約，VS自動生成相應的類。這些自動生成的類構成了您的代理 - 不是您在服務端定義的類。他們可能看起來非常相似，但他們是完全不同的類。

由於XSD僅表示結構（而不是行爲），因此從WSDL繼承到代理的原始數據合約的唯一部分是由[DataMember]標記的屬性。

您看到的構造函數是自動生成的類的默認構造函數。

有幾種方法可以在服務和客戶端之間共享數據類，但這意味着您將它們緊密地結合在一起，因此對於大多數情況下，這不被推薦。

來源

2009-11-06 13:02:22

從元數據（wsdl）創建代理時，我們共享客戶端的合同（接口和數據成員）而不是客戶端的行爲（方法）。

如果您需要共享某種實現邏輯的強制客戶端如何與您的服務進行交互，那麼你可以考慮：

提供一個客戶端的dll封裝了業務代理，並執行任何必要的行爲（初始化，方法順序等）。
驗證數據合同值，當您收到它來驗證它們落入已知範圍內。

HTH，

來源

2009-11-06 13:09:31

WCF服務客戶端訪問內部構件

回答

相關問題