刚看了 zwchen 的 MiniFramework 和 giscat 的 Agile Java Framework, 发现其中一个共同的思想就是通过 Map和List 来实现对象图, 在框架各层之间传递共享. 好像有类似思路和实践的同仁也不少.
这确实是比通常的 ORM 更容易实现和掌握的一条途径, 不过同时也损失了 强类型OO 的类型信息, 和 强语法 的 引用语法检查 能力, 在 重构 方面对 迭代式的敏捷过程 有负面影响.
TOB ([url]http://tob.ableverse.org[/url]) 是我最近搞的一个关系模型的Java对象数据库. 如果在框架中用 TOB 来作为持久层的话, 可能上面的好处可以兼得, 因为TOB是以OO对象为中心的:
当你从 TOB 获得一个 持久对象 的引用时, 必然是已经包含了它的整个持久拓扑结构的, 也就没有必要再由程序去自己构造 Map/List 结构, 持久类写成兼容 JavaBean 规范的话, 应该也可以通过 OGNL 访问.
从应用的角度来看, 相当于你可以用SQL查询到已经在内存中构造好的对象拓扑图中的特定节点, 然后再通过持久对象引用遍历到所有和它相关的节点.
当然TOB假定系统内存可以放得下数据库管理下的最大的拓扑图, 不过随着64位普及, 内存越来越便宜, 大部分项目的硬件环境应该可以适用.
大家有兴趣和时间的请研究研究.
我目前正在写tob数据模型的论文, 进度更新在 [url]http://www.ableverse.org/articles/orkm.html[/url]
tob教程也正在写: [url]http://www.ableverse.org/tutorials/tob/[/url]
这确实是比通常的 ORM 更容易实现和掌握的一条途径, 不过同时也损失了 强类型OO 的类型信息, 和 强语法 的 引用语法检查 能力, 在 重构 方面对 迭代式的敏捷过程 有负面影响.
TOB ([url]http://tob.ableverse.org[/url]) 是我最近搞的一个关系模型的Java对象数据库. 如果在框架中用 TOB 来作为持久层的话, 可能上面的好处可以兼得, 因为TOB是以OO对象为中心的:
当你从 TOB 获得一个 持久对象 的引用时, 必然是已经包含了它的整个持久拓扑结构的, 也就没有必要再由程序去自己构造 Map/List 结构, 持久类写成兼容 JavaBean 规范的话, 应该也可以通过 OGNL 访问.
从应用的角度来看, 相当于你可以用SQL查询到已经在内存中构造好的对象拓扑图中的特定节点, 然后再通过持久对象引用遍历到所有和它相关的节点.
当然TOB假定系统内存可以放得下数据库管理下的最大的拓扑图, 不过随着64位普及, 内存越来越便宜, 大部分项目的硬件环境应该可以适用.
大家有兴趣和时间的请研究研究.
我目前正在写tob数据模型的论文, 进度更新在 [url]http://www.ableverse.org/articles/orkm.html[/url]
tob教程也正在写: [url]http://www.ableverse.org/tutorials/tob/[/url]