面向 Java 开发人员的 db4o 指南: 超越简单对象

核心提示： 自然，针对这套测试运行 JUnit 测试运行器会生成预计输出：要么是“.”，面向 Java 开发人员的 db4o 指南: 超越简单对象(6)，要么是绿条，这与所选择的测试运行器有关（控制台或 GUI），它们的引用将置为空，我的工作就是显式地从数据库激活那些对象，注意，一般

自然，针对这套测试运行 JUnit 测试运行器会生成预计输出：要么是“.”，要么是绿条，这与所选择的测试运行器有关（控制台或 GUI）。注意，一般不赞成向控制台写数据 —— 应该用断言进行验证，而不是用眼球 —— 不过在探察测试里，做断言之前看看得到的数据是个好办法。如果有什么没通过，我总是可以注释掉 System.out.println 调用。（可以自由地添加，以测试您想测试的其他 db4o API 特性。）

从这里开始，假定清单 4 中的测试套件包含了代码示例和测试方法（由方法签名中的 @Test 注释指明。）。

存取结构化对象

存储结构化对象很大程度上和以前大部分做法一样：对对象调用 db.set()，OODBMS 负责其余的工作。对哪个对象调用 set() 并不重要，因为 OODBMS 通过对象标识符（OID）对对象进行了跟踪，因此不会对同一对象进行两次存储。

Retrieving 结构化对象则令我不寒而栗。如果要检索的对象（无论是通过 QBE 或原生查询）拥有大量对象引用，而每个被引用的对象也有着大量的对象引用，以此类推。这有一点像糟糕的 Ponzi 模式，不是吗？

避免无限递归

不管大多数开发者的最初反应（一般是 “不可能是这样的吧，是吗？”）如何，无限递归在某种意义上正是 db4o 处理结构化对象的真正方式。事实上，这种方式是绝大多数程序员希望的，因为我们都希望在寻找所创建的对象时，它们正好 “就在那里”。同时，我们也显然不想通过一根线缆获得整个世界的信息，至少不要一次就得到。

db4o 对此采用了折衷的办法，限制所检索的对象数量，使用称为激活深度（activation depth）的方法，它指明在对象图中进行检索的最低层。换句话说，激活深度表示从根对象中标识的引用总数，db4o 将在查询中遍历根对象并返回结果。在前面的例子中，当检索 Ben 时，默认的激活深度 5 足够用于检索 Jessica，因为它只需要仅仅一个引用遍历。任何距离 Ben 超过 5 个引用的对象将无法 被检索到，它们的引用将置为空。我的工作就是显式地从数据库激活那些对象，在 ObjectContainer 使用 activate() 方法。