c# - 带有方法的 WCF DataContract 类

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()

我建议将序列化的前端代码和对象与持久性分开。我什至会推荐一个单独的数据库访问层，它不了解其上层的层或责任，这些层拥有传输和业务逻辑。

如果数据库持久性在您的数据契约和传输层中，随着时间的推移，您将无法梳理和替换层(如果需要)——这将是一大堆代码。

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

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

希望对您有所帮助。