2

我们有一个软件基础设施,其工作方式与软件构建系统非常相似:信息从不同来源收集并用于生成一些输出。与传统的软件构建一样,我们有不同类型的输出、依赖树等。

主要区别在于我们的源、中间结果和输出不是天生基于文件的。相反,它们是(唯一可寻址的)数据对象。

现在,我们正在结合传统的构建系统 (SCons) 将我们的数据结构映射到文件和目录,但这并不能扩展,无论是性能还是(更重要的是)可维护性。因此,我正在寻找一种从头开始为此目的而构建的基础设施。

作为说明,假设您有 3 个 XML 文档AB并且C. 假设B/foo/bar要从A/x/y和计算A/x/z,同样C/a/b是从 计算A/x/y。我需要一个基础设施来

  1. 实现这些关系(即转换及其依赖关系)
  2. 更改后自动重新构建相关部分

使用文件的一个主要问题是,如果我将 和 映射到某些文件A,并且使用传统的构建系统,那么任何的更改都会触发和的重建,即使和(的原始依赖项)没有被修改。因此,对于细粒度的依赖解决方案,我需要将每个映射,而不是映射到文件,而是映射到每个子目录代表一个元素,文件代表属性等的目录。正如我所说,这不适用于我们。BCA.xmlB.xmlC.xmlA.xmlB.xmlC.xmlA/x/yA/x/zBABC

(请注意,我们的系统实际上并不是基于 XML)

现在,我正在寻找任何指向这个方向的现有软件、基础设施或概念,无论实现语言和底层数据结构如何。

4

2 回答 2

2

因此,没有什么可以完全解决您的问题,但是有一些工具可能会让您比现在更接近一点:

1)您也许可以使用 Fuse 将一些东西放在一起,这样您就可以更好地控制数据对象如何映射到文件。Fuse 基本上允许您从所需的任何支持数据构建任意文件系统。(python 绑定非常友好,但也有许多其他语言接口可用)。然后,您可以使用传统的构建工具,并利用与您的数据更好地关联的文件之类的对象。

2) Cmake 有一种非常可扩展的语言来编写自定义目标,您可能可以将其投入使用。不幸的是,它的语言非常具有教学性,并且学习曲线陡峭,所以它不是我的首选。

于 2013-03-23T18:55:56.257 回答
2

听起来您需要像GemStone/S这样的活动对象数据库管理系统 ( ODBMS ) 。ODBMS 提供传统的持久性服务,没有将数据结构映射到文件的旧成本以及对象技术的众所周知的好处。正如您提到的依赖树和可寻址对象,在 ODBMS 中,导航引用作为其数据的一部分存储,允许表示/访问对象之间的任何复杂交互模式。当您预测使用继承、对象嵌套和交叉引用的系统时,尤其如此。

尽管对象引擎对于您的要求来说可能看起来过大,但对于大型生产业务系统来说,在并发和多用户环境中使用 OODBM 存储和执行方法是很常见的。它不是免费的,因为你必须投资于等式中的人性部分(教育和经验),但一旦克服了最初的恐惧,它就会获得投资回报。

对于在进行更改(来自播音员的通知)后重新构建(订阅)部分,您可以使用观察者设计模式或其变体之一(SASE公告框架)来实现您的公告/订阅架构。正如您已经注意到的那样,在这种类型的事件框架下,存在传统的基于文件的解决方案难以解决的内在问题。例如,依赖机制通常管理一个对象的替换,或者在您的示例中,一个 XML 文档被另一个替换。任何现代事件框架都应该在删除对象时进行管理,插入旧对象的所有依赖项都更新为新引用。

最后,还有一个免费的GemStone/S 堆栈,其中包含对象依赖框架,因此您可以尝试使用真正的对象数据库。

于 2013-03-24T03:29:22.357 回答