構建不是以文件爲中心的系統

Question

我們有一個軟件基礎架構，其功能非常像軟件構建系統：信息從不同來源收集並用於生成一些輸出。就像在傳統的軟件構建我們有不同類型的輸出，依賴樹木等

的主要區別是，我們的消息來源，中間結果和產出不是固有的文件爲主。相反，它們是（唯一可尋址的）數據對象。

現在，我們正與傳統構建系統（使用SCons）映射我們的數據結構，文件和目錄的組合，但是這並沒有形成規模，既w.r.t.表現，但（更重要的）w.r.t.可維護性。因此，我正在尋找一種從零開始爲此目的而構建的基礎架構。

舉例說明，假設您有3個XML文檔A，B和C。假設B/foo/bar將從A/x/y和A/x/z計算，並且類似地C/a/b從A/x/y計算。我需要一個基礎設施

1. 實現這些關係（即轉換以及它們的依賴）
2. 自動重新建立相關部分的變化是由

的一個主要問題後使用的文件是如果我一個傳統的構建系統映射A，B和C一些文件A.xml，B.xml和C.xml和使用，然後任何變化A.xml將觸發一個重建的B.xml和C.xml，即使A/x/y和A/x/z（的B原依賴性）不被修改。對於細粒度的解決依賴我因此需要在每個A，B和C映射不是一個文件，而是每個子目錄代表一個元素的目錄，文件屬性的代表，等等。正如我所說，這確實不適合我們的規模。

（請注意，我們的系統是不是實際上是基於XML）

現在我正在尋找任何現有的軟件，基礎設施或概念指向這個方向，無論實現語言和底層的數據結構。

Answer 1

這聽起來像你需要一個活動對象數據庫管理系統（ODBMS），如GemStone/S。 ODBMS提供傳統的持久性服務，而不需要將數據結構映射到文件的舊成本以及對象技術的衆所周知的好處。正如你所提到的依賴樹和可尋址對象，在ODBMS中，導航引用被存儲爲其數據的一部分，允許表示/訪問對象之間的任何複雜的交互模式。當您預測使用繼承，對象嵌套和交叉引用的系統時，情況尤其如此。

雖然對象引擎可能看起來超大，但您的需求很大，大規模生產業務系統通常在併發和多用戶環境中使用OODBM存儲和執行方法。它不是免費的，因爲你必須投資於方程的人類部分（教育和經驗），但是一旦最初的恐懼得到克服，它將支付投資回報。

對於重樓（認購）部分變更（由播音員通知）製成後，您可以使用Observer design pattern，或其變體（SASE或Announcements framework）之一，實現您公佈/訂閱架構。在這種類型的事件框架下，存在着傳統的基於文件的解決方案難以解決的固有問題，正如您已經注意到的那樣。例如，依賴關係機制通常是由另一個管理對象的替換，或者在您的示例中是一個XML文檔。任何現代事件框架都應該在刪除對象時進行管理，將插入舊對象的所有依賴項更新爲新的引用。

最後，有一個免費的GemStone/S stack其中包括對象依賴框架，所以你可以嘗試一個真正的對象數據庫。

Answer 2

所以沒有想到的是解決了究竟你的問題，但也有可能讓你一些工具靠近一點點比你現在是：

1）你也許可以一起使用保險絲扔東西可以更好地控制數據對象如何映射到文件。 Fuse基本上允許你從任何你想要的數據構建任意的文件系統。 （python bindings非常友好，但也有一些其他語言接口可用）。然後，您可以使用傳統的構建工具，並利用與您的數據更好關聯的類似文件的對象。

2）CMake的有寫，你也許能按到服務的定製目標相當擴展的語言。不幸的是，它的語言非常具有教學意義，並且具有陡峭的學習曲線，所以它不會是我的第一選擇。