2

我有一份服务合同：

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

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

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

我认为构造函数逻辑不属于我们的服务合同，因为如果您使用“添加服务引用...”并且正在使用由 Visual Studio 生成的代理类，该代码将不起作用。

在内部，我们使用 Castle DynamicProxy，如下所示。但是，我希望我们的开发人员避免在服务合同类中使用构造函数逻辑，以防我们由于某种原因无法使用 DynamicProxy。

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

4

2 回答 2

1

只有在首先创建对象以通过您的服务进行传输时，它才会有所不同。如果您希望SomeEnumMember在实例化时使您的默认值不同以方便传输，则可能有意义：

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

在接收方，这不会有任何区别，因为值（我认为，并且来自您的测试）无论如何都是由发件人明确设置的。此外，接收器实例化/反序列化对象将是额外/浪费的工作，但很可能这是可以忽略不计的开销。

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

于 2012-05-11T20:06:28.767 回答
1

我同意你的看法，我认为构造函数逻辑不属于那里，而且我从未真正使用过其中包含构造函数逻辑的 wcf。

于 2012-05-11T19:55:32.713 回答