3

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

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

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

4

3 回答 3

3

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

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

[DataContract]
public class LogEntry
{
    ...

     public void WriteToDatabase()

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

如果数据库持久性在您的数据合同和传输层中，那么随着时间的推移，如果需要，将不可能分开和替换层 - 这将是一团代码。

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

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

希望有帮助。

于 2011-09-25T02:25:26.770 回答
1

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

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

于 2009-07-15T18:24:23.050 回答
0

实际上，这真的取决于上下文

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

如果您缺乏一切，并且您不希望任何人比您正在开发的客户端连接到 Web 服务，并且您对这种方法感到满意，请执行此操作。

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

请注意，在 WCF 命名管道上下文中，您可能有兴趣在客户端和服务器共享的程序集中仅实现一次此协定。在这种情况下，您可能会向客户端公开服务器的签名。

于 2009-07-15T18:44:29.080 回答