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,它解决了很多问题,而且在大多数情况下我需要为我的项目存储非规范化的对象,但有时我们可能会在单个存储中需要混合设计.
解决方法
在数据库级别,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类(模型类)才能从数据库中保存对象.这很棘手,因为它需要注入数据库,或者您需要一个静态对象来进行数据库访问,这也很棘手.
>访问部门看起来非常便宜,但事实上,它会触发数据库操作,它可能很慢,可能会失败.这完全是来自呼叫者的隐藏.
>在1：n关系中,事情变得更加复杂.例如,部门是否还会公开雇员名单？如果是这样,那真的是一个列表(即一旦你开始阅读第一个,所有员工必须被反序列化吗？)或者它是一个懒惰的MongoCursor？
>更糟糕的是,通常不清楚应该使用什么样的缓存.假设你得到myDepartment.Employee [0] .Department.Name.显然,这段代码并不聪明,但想象一下,调用堆栈中有一些专门的方法.他们可能会像这样调用代码,即使它更隐藏.现在,一个天真的实现实际上会再次反序列化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,级联更新等,它就会分开.
