带有方法的WCF DataContract类

这更像是一种哲学/最佳实践问题，而不是技术问题。

是否有任何强有力的论据反对使用仅在服务器端使用的方法编写DataContract类？ 或者没有使用DataMember属性修饰的其他属性呢？

例如：

[DataContract] public class LogEntry { [DataMember] public string Message { get; set; } [DataMember] public string Severity { get; set; } public string SomeOtherProperty { get; set; } ... public void WriteToDatabase() { ... } } 

虽然使用扩展方法可以使它更容易，但是不这样做似乎是我想要避免的大量额外工作。 但是，作为一名优秀的开发人员，我想知道这样做是不好的做法。

Answer 1

从技术上讲，您可以使用数据协定在同一个类中添加实现。 只有属性的属性才会被序列化。

在您的示例中，您拥有对象，传输以及如何在同一个类中写入数据库：

 [DataContract] public class LogEntry { ... public void WriteToDatabase() 

我建议你的前端代码和被序列化的对象与你的持久性是分开的。 我甚至建议一个单独的数据库访问层，它不知道上面的层的层或责任，它们拥有传输和业务逻辑。

如果数据库持久性存在于数据协定和传输层中，则随着时间的推移，如果需要，将无法分离和替换层 – 它将是一个代码块。

分离层也有助于测试。 能够在没有完整系统的所有依赖性的情况下测试代码单元是有价值的。 例如，如果您将数据库持久性分开，甚至将其与接口分离，则可以对业务逻辑进行unit testing，您可以使用子集内存实现替换persistance。

如果不知道传输的对象，则将这些对象传递给DAL的一个问题就变成了问题。 为了强制分离，我已经看到了一个类型dll，它只包含带有数据契约装饰的这些结构，拥有传输的服务层和一个引用类型dll的BLL / DAL。

希望有所帮助。

Answer 2

您当然可以添加任何您想要的类型，因为就WCF而言，只有明确选择作为DataMembers才是合同的一部分，并且将被序列化。

我认为不将无关成员纳入合同更为清晰，因为当您使用该类型时可能会造成混淆。

Answer 3

实际上，它实际上取决于背景

通过上下文我的意思是：第一个项目管理上下文：资金预算/时间/开发人员级别/项目的预期生命周期然后WCF上下文：它是web服务（wsdl）还是命名管道传输

如果你缺少一切，并且你不期望任何人，而不是你正在开发的客户连接到网络服务，你觉得这种方法很舒服。

在所有其他情况下，我建议将合同代码与实现细节彻底分开。

请注意，在WCF namedpipe上下文中，您可能只想在客户端和服务器共享的程序集中实现此契约一次。 在这种情况下，您可能会向客户端公开服务器的签名。