Question

我有服务合同：

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

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

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

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

在内部，我们正在使用Castle DynamicProxy，如here所示。但是，我希望我们的开发人员避免服务契约类中的构造函数逻辑，以防我们因某些原因无法使用DynamicProxy。

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

Answer 1

我同意你的意见，我不认为构造函数逻辑属于那里，我从未真正使用过具有构造函数逻辑的wcf。

Answer 2

在通过您的服务传输的第一个位置创建对象时，它可能会有所不同。如果您希望在实例化时将SomeEnumMember的默认值设置为为方便而传输，则可能有意义：

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

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

通常，您的数据传输对象不应包含逻辑。也许取决于您的应用程序架构，如果您在除了传输信息之外的许多地方使用此对象，它可能是有意义的。虽然我会质疑这种架构：我喜欢将与客户端 - 服务器通信有关的对象从我的应用程序架构的其余部分中抽象出来。这样我就可以自由地对其进行更改（专门的序列化，体系结构更改等），而不会严重影响我的应用程序的其余部分。

服务合同中的构造函数逻辑

2 个答案: