服务协定中的构造函数逻辑

本文关键字：构造函数 服务 | 更新日期: 2023-09-27 18:33:59

我有一个服务合同：

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

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

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

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

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

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

服务协定中的构造函数逻辑

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

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

在接收端，这不会有什么区别，因为无论如何，发送方都会明确设置值(我认为，以及您的测试(。 此外，您的接收器实例化/反序列化对象将是额外/浪费的工作，但很可能这是一个可以忽略不计的开销。

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

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

相关文章：