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()
  {
    ...
  }
}

不这样做似乎会增加很多额外的工作量，我宁愿避免，但是使用扩展方法可能会更容易。 但是，作为一名好的开发者，我在想是否这样做是不好的实践。

- jeanml

---

这是https://dev59.com/3kjSa4cB1Zd3GeqPFGc-的精确副本。 - John Saunders

谢谢，我在研究时没有看到这个。 似乎并没有一个单一的有效答案，但我倾向于保持DataContract简洁明了。我很喜欢从DataContract派生一个类的想法，因为它比扩展方法更灵活，即您还可以添加其他属性。 - jeanml

Answer 1

从技术上讲，您可以在与数据契约相同的类中添加实现。只有被标记的属性会被序列化。

在您的例子中，您将对象、传输和如何写入数据库的方法放在了同一个类中：

[DataContract]
public class LogEntry
{
    ...

     public void WriteToDatabase()

我建议前端代码和被序列化的对象与持久层分开。我甚至建议使用单独的数据库访问层，它不知道它上面的层或者负责传输和业务逻辑的职责。

如果数据库持久性在数据契约和传输层中，则随着时间的推移，如果需要替换层，则无法将其解开 - 它将成为一坨代码。

分离层还有助于测试。能够测试一个没有完整系统依赖的代码单元是非常有价值的。例如，如果您分离数据库持久性并甚至通过接口解耦它，以进行业务逻辑的单元测试，您可以使用子集内存实现替换持久性。

一个问题是如何将这些对象传递给DAL，如果它不知道被传输的对象。为了强制分离，我看到了一个类型DLL，其中仅包含具有数据契约装饰的这些结构，一个拥有传输权并且BLL/DAL都引用types dll的服务层。

希望这有所帮助。

- bryanmac

Answer 2

你当然可以向类型中添加任何你想要的内容，因为就 WCF 而言，只有显式选择作为 DataMembers 的成员才是合同的一部分，并将被序列化。

我认为最好不要将无关的成员放入合同中，因为在使用该类型时可能会产生混淆。

- Andrew Hare

Answer 3

实际上，这取决于上下文。

所谓的上下文是指： 首先是项目管理方面：资金预算/时间/开发人员水平/预期项目寿命 然后是 WCF 方面：它是一个 Web 服务（wsdl）还是一个命名管道传输

如果你在所有方面都很短缺，而且你不希望除正在开发的客户端之外的任何人连接到 Web 服务，并且你对这种方法感到舒适，请这样做。

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

请注意，在 WCF 命名管道上下文中，您可能只对在由客户端和服务器共享的程序集中一次实现此合同感兴趣。 在这种情况下，您可能会冒着向客户端公开服务器签名的风险。

- jonathan suard