Question

我有一个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的第二个构造函数，而不是默认的构造函数，我试图使用内部函数隐藏它。

但实际发生的事情正好相反。在客户端应用程序中，我只能看到内部构造函数。

有什么想法吗？

Answer 1

在WCF中，当您添加服务引用时，您将获得客户端代理 - 但对于数据，仅数据（以及无行为）正在反序列化 - 这是唯一在XML模式中存储和传输的东西。

您的客户端代理无法发现和使用任何其他构造函数，数据合同对象上的任何其他方法 - 严格仅数据部分正在通过网络传输。

此外，标准DataContractSerializer（WCF默认使用）在从收到的消息中反序列化数据时甚至不会调用任何构造函数 - 它只会为您的数据分配足够大的内存块，然后移动位进入适当的内存位置。绕过任何构造函数（这也解释了为什么DataContractSerializer在其数据类上不需要公共的无参数构造函数 - 就像XmlSerializer一样）。

Answer 2

默认情况下，WCF遵循面向服务的一个核心原则：

服务共享合同，而不是类

这意味着当您在Visual Studio中创建服务引用时，VS会向服务询问有关服务的元数据。此合约以WSDL和XSD表示，并根据合同自动生成相应的类。这些自动生成的类构成了您的代理 - 而不是您在服务端定义的代理。它们可能看起来非常相似，但它们是完全不同的类。

由于XSD仅表示结构（而不是行为），因此从WSDL转移到代理的原始数据合同的唯一部分是由[DataMember]标记的属性。

您看到的构造函数是自动生成的类的默认构造函数。

您可以通过多种方式在服务和客户端之间共享数据类，但这意味着您将它们紧密地结合在一起，因此对于大多数情况，建议不要这样做。

Answer 3

在从元数据（wsdl）创建代理时，我们与客户共享合同（接口和数据成员）而非行为（方法）。

如果您需要共享某种实现逻辑来强制客户端与您的服务进行交互，那么您可以考虑：

提供一个客户端dll，它封装了服务代理并强制执行任何必要的行为（初始化，方法顺序等）。
在收到数据合同时验证数据合同值，以验证它们是否在已知范围内。

HTH，

ž

访问内部成员的WCF服务客户端

3 个答案: