C# 在WCF服务中创建专用数据成员

在WCF服务中创建私有数据成员是一个好主意吗？如果这是一个好做法，那么当客户机只调用服务的方法时，我们初始化这些成员变量

仅将数据契约用作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;
    }
}

---

如果您对互操作性感兴趣，我认为这通常不是一个好的实践

首先，创建一个契约（操作契约、消息契约、数据契约等），以明确地指定支持什么和不支持什么。它明确地公开指定了这些内容。当你开始宣布私人成员是公共合同的一部分时，它会变得非常混乱，非常快。对于跟随您的程序员来说，识别正在发生的事情会成为一个问题

您可能试图在数据契约中封装逻辑，这不是数据契约的目的。正如@CodeCaster所建议的，这种操作应该在数据契约类之外执行。即使是像构造函数填充默认值这样的简单事情也会有问题。这种逻辑也应该在DataContract类之外执行

此外，当您将私有成员声明为

[DataMember]

s时，您依赖的是数据契约序列化程序的非标准实现细节，即它可以读取/写入非公共成员，即DataConstructSerializer（至少在.NET平台上）可以执行您在自己的代码中无法执行的操作。你依靠的是“魔法”。虽然这个“魔术”帮助DataConstructSerializer提供惊人的性能，但我认为您不应该依赖于它的实现细节。例如，您会发现这样的DataContract类无法与Silverlight应用程序共享，因为在该平台上DataContractSerializer无法读取/写入非公共成员

但是，像所有的“实践”一样，你必须考虑你的情况。如果互操作性和可维护性不是一项要求，则上述大部分内容不相关，可以忽略不计：