C# 服务契约中的构造函数逻辑

我有一份服务合同：

[DataContract]
public class Something
{
    [DataMember]
    public MyEnum SomeEnumMember {get;set;}
}

我们的一些开发人员正在做这样的事情：

public Something()
{
    SomeEnumMember = MyEnum.SecondEnumValue;
}

我认为构造函数逻辑不属于我们的服务合同，因为如果您使用“添加服务引用…”并使用VisualStudio生成的代理类，则该代码将不起作用

在内部，我们使用Castle DynamicProxy，如图所示。然而，我希望我们的开发人员避免在服务契约类中使用构造函数逻辑，以防出于某种原因无法使用DynamicProxy

---

那么：构造函数逻辑在这些类中有地位吗？或者，作为一种最佳实践，我们是否应该将它们更多地视为DTO，并在没有行为的情况下实现它们？

我同意你的看法，我认为构造函数逻辑不属于那里，而且我从来没有实际使用过包含构造函数逻辑的wcf。

它可能只会在首先创建要通过服务传输的对象时起作用。如果您希望在实例化时将

SomeEnumMember

的默认值设置为不同的值以便于传输，则可以这样做：

var mySomething = new Something();
mySomething.SomeEnumMember = MyEnum.SecondEnumValue; //this line may be omitted if it's set automatically by the constructor
SendData(mySomething);

在接收端，它不会有任何区别，因为值（我认为，以及您的测试中的值）无论如何都是由发送方显式设置的。此外，接收者实例化/反序列化对象将是额外的/浪费的工作，但这很可能是可以忽略不计的开销

---

一般来说，数据传输对象不应该包含逻辑。如果您在许多地方使用这个对象而不仅仅是传输信息，那么它可能是有意义的，这取决于您的应用程序体系结构。尽管我会质疑这种架构：我喜欢将与客户机-服务器通信相关的对象从我的应用程序架构的其余部分抽象出来。这样，我可以自由地对其进行更改（专门的序列化、架构更改等），而不会严重影响应用程序的其余部分。

我可能错了，但在反序列化对象时，如果传入的XML（或其他内容）没有属性值，则它不会从其原始值修改它。（另一方面，我可能是错的，并且将始终指定类型的默认值）如果我是对的，那么在构造函数中指定一个值可以设置默认值（如果没有显式提供）。除此之外，我不认为这是一个很好的理由。我不认为逻辑/方法应该在类中，如果它的目的是严格地在域之间传输信息。谢谢。这正是我的思路：“如果逻辑/方法的目的严格来说是在域之间传输信息，我认为它不应该在类中。”我们今天早上运行了一些测试，枚举默认为第一个成员——0，正如预期的那样——尽管我们在构造函数中将其初始化为其他成员。只是补充一下，这可能取决于你对课堂的使用情况。如果它严格用于通过服务进行数据传输，并转换为另一个域对象供您的应用程序使用，那么它可能没有任何用途。如果您在整个应用程序中重用它，并且依赖于除类型default之外的属性的默认值，那么它是有意义的（就像对任何其他类一样）。但是，我建议您重构您的体系结构，以避免对数据传输对象的依赖。我只把它们看作DTO，根本不希望它们有任何行为。我认为有两个原因导致我看到这一点，1）我们使用DynamicProxy，因此构造函数逻辑受到攻击，2）它被视为默认枚举值的解决方法。我只是不想在接下来的六个月里，有人在不使用DynamicProxy的情况下连接到我们的一项服务，并想知道为什么事情会发生奇怪的变化。嗯，初始化代码没有命中@杰克，科尔顿，我也是这么想的。此外，添加到DataContract对象中的任何逻辑都意味着可能需要测试或可能导致错误的逻辑。让DataContract对象在服务中抛出异常是不愉快的。不过，你的案子很琐碎，不太可能引起任何问题。然而，它可能会让开发人员考虑向DataContract对象添加更多的非琐碎代码（验证、业务逻辑、日志记录等），这可能会在将来引起麻烦或导致意外行为。谢谢你的讨论。