C# 带有方法的 WCF DataContract 类

WCF DataContract class with methods

提问by jeanml

This is more of a philosophical/best-practice sort of question rather than a technical problem.

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

Are there any strong arguments against writing a DataContract class with methods that are to be used server-side only? Or what about additional properties that are not decorated with the DataMember attribute?

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

For example:

例如：

[DataContract]
public class LogEntry
{
  [DataMember]
  public string Message { get; set; }
  [DataMember]
  public string Severity { get; set; }

  public string SomeOtherProperty { get; set; }

  ...

  public void WriteToDatabase()
  {
    ...
  }
}

Not doing it seems like an awful lot of extra work that I would prefer to avoid, although using extension methods could make it easier. But, as a good developer, I am wondering if it is bad practice to do so.

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

回答by Andrew Hare

You certainly can add anything you want to the type because as far as WCF is concerned, only memebers that have explicitly opted-in as DataMembersare part of the contract and will be serialized as such.

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

I think that it is cleaner to notput extraneous members into a contract as that can be confusing when you are using the type.

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

回答by Andrew Hare

Actually, it really depends on the context

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

by context I mean: First project management context : money budget/time/developpers level/expected life time of your project Then WCF context : is it a webservice (wsdl) or a namedpipe transfer

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

If you are short on everything and you do not expect anybody than the clients you are developping to connect to the web service and you feel confortable with this approach do it.

如果您什么都缺，并且您不希望除了您正在开发的客户端之外的任何人连接到 Web 服务，并且您对这种方法感到满意，请这样做。

In all the other case, I would suggest to cleanly split the contract code from implementation details.

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

Note that in a WCF namedpipe context, you could be interested in implementing only once this contract in an assembly shared by both the clients and the server. In this case you risk to expose to clients signatures of the server.

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

回答by bryanmac

Technically you can add implementation in the same class with the data contract. Only those properties attributed will get serialized.

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

In your example, you had the object, transport and how to write to database in the same class:

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

[DataContract]
public class LogEntry
{
    ...

     public void WriteToDatabase()

I would recommend that your front end code and objects that get serialized is separate from your persistance. I would even recommend a separate database access layer which has no knowledge of the layers or responsibility of the layers above it which own transport and business logic.

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

If the database persistence is in your data contract and transport layer, over time, it will be impossible to tease apart and replace layers if you need to - it will be one blob of code.

如果数据库持久性在您的数据契约和传输层中，随着时间的推移，如果需要，将无法拆分和替换层 - 这将是一团代码。

Separating the layers also helps with testing. Being able to test a unit of code without all the dependencies of a full system is valuable. For example, if you separate your database persistance and even decouple it with an interface, for unit testing your business logic, you could replace the persistance with a subset in-memory implementation.

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

One issue becomes how you pass those objects down to the DAL if it has no knowledge of the objects that get transported. To enforce separation, I've seen a types dll which simply contains these structures with data contract decorations, a services layer that owns the transport and a BLL/DAL which both reference the types dll.

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

Hope that helps.

希望有帮助。