c# - 数据模型和服务模型之间的继承模式是什么？

Question

我们的一个产品包含多个 WCF 服务，其业务层都位于同一数据访问层之上，该数据访问层提供对 NoSql 数据库 (mongodb) 的访问:

  WCF   WCF   WCF
   |     |     |
   BL    BL    BL
   |     |     |
 Data Access Layer        <-- PageInfoResult currently defined here
         |
      mongodb

因为每个服务都包含一个或多个接受或返回特定类型 (PageInfoResult) 的方法，该类型也直接存储在数据库中，所以 PageInfoResult 类在 DAL 中定义了 Bson 序列化属性(对于 mongodb)和数据协定序列化属性(对于 WCF)。

例子:

[DataContract]
public class PageInfoResult
{
    [BsonId]
    [DataMember]
    public string PageUrl { get; set; }

    [BsonElement("status")]
    [DataMember]
    public int HttpStatusCode { get; set; }

    [BsonElement("score")]
    [DataMember]
    public int OurProprietaryPageScore { get; set; }

    [BsonElement("data")]
    [DataMember]
    public SomeOtherClass OtherData { get; set; }

    // ... other properties ...
}

所以具体问题是:

1. 每个 WCF 服务是否应该重新定义 DAL 的数据模型然后绘制成图表，或者 DAL 是否可以合法地成为定义模型的唯一位置？
2. 如果每个服务都应该重新定义 DAL 中的每个模型，服务模型是否应该继承数据模型(或者反之亦然)？

在更一般的意义上:

1. 什么是正确的、面向对象的方法来定义非常相似(或相同)的服务和数据模型？
2. 在处理模式数据库与无模式数据库(MsSql 与 MongoDB)时，在处理方法上是否存在差异？

Answer 1

1. 数据模型和 WCF 契约是两个完全不同的东西。他们不应该是一样的!如果它们相同，则说明您的服务层与数据访问层的耦合过于紧密。

2. 我的意见是“不”。继承仍然意味着两者之间的紧耦合。

最好根据您向客户公开的内容来考虑服务层。您的 WCF 数据契约(Contract)应仅包含您的客户调用您的服务所需的信息。

服务层的数据契约和您所称的数据模型之间的“转换”很可能发生在您的业务层中。更好的是，将您的业务层视为数据契约和数据模型的“消费者”或“用户”。

同样，这只是我的意见，但我确实认为最好将它们视为完全独立的。

编辑:(来自评论) 有时我们努力去耦合和增加只会使解决方案的架构复杂化的复杂层。与我的回答相反，也许“保持简单”呢？如果是这样，就不需要涉及继承，只要对你有用，就做你正在做的。