c# - 如何处理像 Mongo 这样的文档数据库中单独存储的对象的引用？

Question

这个问题在 Entity Framework 或 NHibernate 等 ORM 中很容易解决，但我在 MongoDb 的 c# 驱动程序中没有看到任何现成的解决方案。假设我有类型 A 的对象集合，引用对象类型 B，我需要将其存储在单独的集合中，以便一旦特定对象 B 发生更改，所有引用它的 A 都需要知道更改。换句话说，我需要规范化这个对象关系。同时，我需要 B 在类中被 A 引用，而不是通过 Id，而是通过类型引用，如下所示:

public class A
{
   public B RefB { get; set; }
}

我是否必须自己处理所有这些引用一致性？如果是这样，哪种方法最好使用？我是否必须在类中同时保留 B 的 Id 和 B 引用，并以某种方式处理同步它们的值，如下所示:

public class A
{
    // Need to implement reference consistency as well
    public int RefBId { get; set; }

    private B _refB;
    [BsonIgnore]
    public B RefB
    {
        get { return _refB; }
        set { _refB = value; RefBId = _refB.Id }
    }
}

我知道有人可能会说关系数据库最适合这种情况，我知道，但我真的必须像 MongoDb 一样使用文档 Db，它解决了很多问题，并且在大多数情况下，我需要为我的项目存储非规范化的对象，但是有时我们可能会需要在单个存储中混合设计。

Answer 1

这主要是一个架构问题，它可能有点取决于个人品味。我将尝试检查利弊(实际上只是利弊，这是非常自以为是):

在数据库级别，MongoDB 不提供强制执行参照完整性的工具，所以是的，您必须自己执行此操作。我建议您使用如下所示的数据库对象:

public class DBObject 
{
    public ObjectId Id {get;set;}
}

public class Department : DBObject 
{
  // ...
}

public class EmployeeDB : DBObject
{
    public ObjectId DepartmentId {get;set;}
}

我建议无论如何在数据库级别使用这样的普通 DTO。如果你想要额外的糖，把它放在一个单独的层，即使这意味着有点复制。 DB 对象中的逻辑需要很好地理解驱动程序对对象进行水合的方式，并且可能需要依赖于实现细节。

现在，您是否想要使用更“智能”的对象是一个偏好问题。事实上，许多人喜欢使用强类型的自动激活访问器，例如

public class Employee
{
    public Department 
    { get { return /* the department object, magically, from the DB */ } }
}

这种模式带来了许多挑战:

它需要 Employee类，一个模型类，能够从数据库中水合对象。这很棘手，因为它需要注入(inject)数据库，或者您需要一个静态对象来访问数据库，这也很棘手。

访问 Department看起来完全便宜，但实际上，它会触发数据库操作，它可能很慢，也可能会失败。这对调用者来说是完全隐藏的。

在 1:n 关系中，事情变得更加复杂。例如，会 Department还公开了 Employees 的列表?如果是这样，那真的是一个列表(即一旦你开始阅读第一个，所有员工都必须反序列化？)还是懒惰的 MongoCursor ?

更糟糕的是，通常不清楚应该使用哪种缓存。假设你得到 myDepartment.Employee[0].Department.Name .显然，这段代码并不聪明，但想象一下有一个带有一些专门方法的调用堆栈。他们可能会像那样调用代码，即使它更隐蔽。现在一个幼稚的实现实际上会反序列化 ref'd Department再次。那是丑陋的。另一方面，积极缓存是危险的，因为您可能实际上想要重新获取对象。

最糟糕的是:更新。到目前为止，挑战主要是只读的。现在假设我调用 employeeJohn.Department.Name = 'PixelPushers'和 employeeJohn.Save() .这是否会更新部门？如果是，对 john 的更改是先序列化，还是在对依赖对象的更改之后序列化？版本控制和锁定怎么样？

很多语义难以实现:employeJohn.Department.Employees.Clear()可能很棘手。

许多 ORM 使用一组复杂的模式来允许这些操作，因此这些问题并非不可能解决。但是 ORM 通常在 100k 到远远超过 1M 行代码(!)的范围内，我怀疑您有这种时间。在一个 RDBMS 中，需要激活相关对象并使用……像 ORM 更严重，因为你不能嵌入例如发票中的行项目列表，因此每个 1:n 或 m:n 关系 必须使用连接表示。这就是所谓的对象关系不匹配。

据我了解，文档数据库的想法是您不需要像在 RDBMS 中那样不自然地分解模型。尽管如此，还是有“对象边界”。如果您将数据模型视为连接节点的网络，那么挑战在于了解您当前正在处理的数据部分。

就我个人而言，我不喜欢在此之上放置抽象层，因为该抽象是有漏洞的，它对调用者隐藏了真正发生的事情，并且它试图用同样的锤子解决所有问题。

NoSQL 的部分想法是您的查询模式必须与数据模型仔细匹配，因为您不能简单地将 JOIN 锤子应用于可见的任何表。

所以，我的观点是:坚持薄层，在服务层执行大部分数据库操作。移动 DTO，而不是设计一个复杂的域模型，该模型在您需要添加锁定、mvcc、级联更新等时立即分解。