3

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

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

PageInfoResult因为每个服务都包含一个或多个方法，这些方法PageInfoResult要么接受或返回特定类型（（对于 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）时，方法是否存在差异？
4

1 回答 1

1

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

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

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

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

同样，这只是我的观点，但我认为最好将它们视为完全独立的。

编辑：（来自评论）有时我们会努力解耦并添加只会使解决方案架构复杂化的复杂性层。与我的回答相反，也许“保持简单”呢？如果是这种情况，则无需涉及继承，只要对您有用，就做您正在做的事情。

于 2012-06-26T19:16:17.083 回答