Question

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

是否有任何强有力的论据反对使用仅在服务器端使用的方法编写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()

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

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

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

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

希望有所帮助。

Answer 2

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

我认为不将无关成员纳入合同更为清晰，因为当您使用该类型时，这可能会让您感到困惑。

Answer 3

实际上，它实际上取决于上下文

通过上下文我的意思是：第一个项目管理背景：项目的资金预算/时间/开发人员级别/预期生命周期然后是WCF上下文：它是webservice（wsdl）还是namedpipe transfer

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

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

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

带有方法的WCF DataContract类

3 个答案: