WCF DataContract类与方法 [英] WCF DataContract class with methods

问题描述

这更多是一种哲学/最佳实践的问题，而不是技术问题.

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

对于使用只能在服务器端使用的方法编写DataContract类是否有强烈的反对意见?还是不使用DataMember属性修饰的其他属性呢?

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]
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.

推荐答案

技术上，您可以将实现与数据协定添加到同一类中.只有那些属性会被序列化.

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.

如果不了解要传输的对象，如何将这些对象向下传递到DAL就是一个问题.为了实现分隔，我已经看到了一个类型dll，它只包含带有数据协定修饰的这些结构，一个拥有传输层的服务层和一个都引用了类型dll的BLL/DAL.

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.

希望有帮助.

这篇关于WCF DataContract类与方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！