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

核心提示： 开始变得复杂了除了讨厌的业务规则之外，有几个重要的情况出现了，面向 Java 开发人员的 db4o 指南: 超越简单对象(4)，首先，当对象 ben 存储到数据库后，我将不得不记得每次手工删除 persons.data 文件，坦白说，OODBMS 除了存储一个对象外，显然还做了其他一些事情

开始变得复杂了

除了讨厌的业务规则之外，有几个重要的情况出现了。首先，当对象 ben 存储到数据库后，OODBMS 除了存储一个对象外，显然还做了其他一些事情。再次检索 ben 对象时，与之相关的配偶信息不仅已经存储而且还被自动检索。

思考一下，这包含了可怕的暗示。尽管可以想见 OODBMS 是如何避免无限递归 的场景，更恐怖的问题在于，设想一个对象有着对其他几十个、成百上千个对象的引用，每个引用对象又都有着其自身对其他对象的引用。不妨考虑一下模型表示子女、双亲等的情景。仅仅是从数据库中取出一个 Person 就会导致追溯到所有人类的源头。这意味着在网络上传输大量对象！

幸运的是，除了那些最原始的 OODBMS，几乎所有的 OODBMS 都已解决了这个问题，db4o 也不例外。

db4o 的探察测试

考察 db4o 的这个领域是一项棘手的任务，也给了我一个机会展示一位好友教给我的策略：探察测试。（感谢 Stu Halloway，据我所知，他是第一个拟定该说法的人。） 探察测试，简要而言，是一系列单元测试，不仅测试待查的库，还可探究 API 以确保库行为与预期一致。该方法具有一个有用的副作用，未来的库版本可以放到探察测试代码中，编译并且测试。如果代码不能编译或者无法通过所有的探察测试，则显然意味着库没有做到向后兼容，您就可以在用于生产系统之前发现这个问题。

对 db4o API 的探察测试使我能够使用一种 “before” 方法来创建数据库并使用 Person 填充数据库，并使用 “after” 方法来删除数据库并消除测试过程中发生的误判（false positive）。若非如此，我将不得不记得每次手工删除 persons.data 文件。坦白说，我并不相信自己在探索 API 的时候还能每次都记得住。