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

Question

这个问题很容易在像Entity Framework或NHibernate这样的ORM中解决,但我没有在MongoDb的c#驱动程序中看到任何现成的解决方案.假设我有A类型的对象集合引用对象类型B,我需要将它存储在单独的集合中,这样一旦特定对象B被更改,所有引用它的A都需要知道更改.换句话说,我需要对象关系进行规范化.同时我需要在类中引用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类(模型类)能够从数据库中水合对象.这很棘手,因为它需要注入数据库,或者您需要一个静态对象来进行数据库访问,这也很棘手.
• 访问Department看起来完全便宜,但事实上,它触发数据库操作,它可能很慢,它可能会失败.这完全是来自呼叫者的隐藏.
• 在1:n关系中,事情变得更加复杂.例如,Department还会公开一个列表Employees？如果是这样,那真的是一个列表(即一旦你开始阅读第一个,所有员工都必须被反序列化吗？)或者它是一个懒惰的MongoCursor？
• 更糟糕的是,通常不清楚应该使用什么样的缓存.让我们说你得到myDepartment.Employee[0].Department.Name.显然,这段代码并不聪明,但想象一下,调用堆栈中有一些专门的方法.他们可能会像这样调用代码,即使它更隐藏.现在,一个天真的实现实际上会Department再次反序列化ref'd .那很难看.另一方面,积极缓存是危险的,因为您可能实际上想要重新获取对象.
• 最糟糕的是:更新.到目前为止,挑战基本上是只读的.现在让我说我打电话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,级联更新等,它就会分开.