我们有一个软件基础设施，其工作方式与软件构建系统非常相似：从不同来源收集信息并用于生成一些输出。就像在传统的软件构建中一样，我们有不同类型的输出、依赖树等。
主要区别在于我们的来源、中间结果和输出本质上并不是基于文件的。相反，它们是（唯一可寻址的）数据对象。
现在，我们正在结合传统的构建系统（SCons）将数据结构映射到文件和目录，但这无法扩展，无论是w.r.t还是。性能，但（更重要的是）w.r.t.可维护性。因此，我正在寻找一个专门为此目的而构建的基础设施。
作为说明，假设您有 3 个 XML 文档A, B and C。这么说吧B/foo/bar是计算自A/x/y and A/x/z，并且类似地C/a/b计算自A/x/y。我需要一个基础设施来
- 实现这些关系（即转换及其依赖关系）
- 更改后自动重新构建相关部分
使用文件的一个主要问题是，如果我映射A, B and C到一些文件A.xml, B.xml and C.xml并使用传统的构建系统，然后any改成A.xml将触发重建B.xml and C.xml， 即使A/x/y and A/x/z（原来的依赖关系B) 不被修改。因此，为了实现细粒度的依赖关系解析，我需要映射每个A, B and C不是文件，而是一个目录，其中每个子目录代表一个元素，文件代表属性等。正如我所说，这对我们来说无法扩展。
（请注意，我们的系统实际上并不是基于 XML 的）
现在，我正在寻找任何指向这个方向的现有软件、基础设施或概念，无论实现语言和底层数据结构如何。
听起来您需要一个活动对象数据库管理系统（ODBMS http://en.wikipedia.org/wiki/Object_database) like 宝石/S http://www.gemstone.com/products/gemstone。 ODBMS 提供传统的持久性服务，无需将数据结构映射到文件的旧成本以及对象技术的众所周知的优点。正如您提到的依赖树和可寻址对象，在 ODBMS 中，导航引用作为其数据的一部分存储，允许表示/访问对象之间的任何复杂交互模式。当您预测一个使用继承、对象嵌套和交叉引用的系统时尤其如此。
尽管对象引擎对于您的需求来说可能显得过大，但大型生产业务系统在并发和多用户环境中使用 OODBM 存储和执行方法是很常见的。它不是免费的，因为你必须投资于人的部分（教育和经验），但一旦克服了最初的恐惧，它就会带来投资回报。
对于更改（来自播音员的通知）后重建（订阅）的部分，您可以使用观察者设计模式 http://en.wikipedia.org/wiki/Observer_pattern，或其变体之一（SASE http://www.object-arts.com/downloads/papers/ExtendingSUnitToTestSASEEvents.pdf or ），实现您的公告/订阅架构。正如您已经注意到的，在这种类型的事件框架下，存在一些难以用传统的基于文件的解决方案解决的固有问题。例如，依赖机制通常用于管理对象（或者在您的示例中是 XML 文档）被另一个对象的替换。任何现代事件框架都应该在删除对象时进行管理，插入旧对象的所有依赖项都将更新为新引用。
终于有免费的了宝石/S 堆栈 http://seaside.gemstone.com/downloads.html其中包括对象依赖框架，因此您可以尝试真实的对象数据库。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
