Posted on 2007-04-22 23:15
canonical 閱讀(1524)
評論(4) 編輯 收藏 所屬分類:
Witrix開發平臺
在商業產品開發中，如何有效的控制同一產品的多個衍生版本是一個非常重要的問題。客戶的需求是多樣化，差異化的。這些差異有些很小，可以通過參數配置，資源裝載，skin切換等方式加以吸收，而有些則要求對界面布局和程序邏輯等作出較大調整。Witrix開發平臺在系統基礎架構方面為程序的客戶化提供了有力的支持。
1. 多版本控制的關鍵首先在于系統良好的模塊劃分。因此Witrix平臺的beans,auth-map(權限歸約規則)等配置文件格式都支持import/include等基礎的分解策略,字符串資源和錯誤碼映射等支持多重定義文件，而對于sql.xml(外部sql語句定義), meta.xml, biz.xml, hbm.xml等配置文件采用分模塊動態裝載機制。
2. 在Witrix系統中定義了一個特殊的custom目錄，規定了一般性的覆蓋規則：custom目錄作為系統根目錄的影子目錄，如果custom目錄下存在同名文件，則優先裝載custom目錄下的文件。例如,如果custom目錄下存在/_config/my/my.biz.xml文件，同時在根目錄下也存在/_config/my/my.biz.xml文件, 則實際裝載的是custom目錄下的實現。這里的一個關鍵在于只有meta.xml(元數據)，biz.xml(BizFlow描述文件)，.lib.xml(tpl模板庫)等具有一定完整性的文件才支持custom機制，而并不是所有資源都采用custom機制。如果每一個tpl文件，css文件，js文件等都優先從custom目錄下裝載，則很快就會出現循環引用，相對路徑計算將會變得非常混亂，更重要的是我們將無法定義資源刪除語義。
3. 元數據文件，BizFlow描述文件，PageFlow描述文件等都支持復雜的extends機制，使得我們在擴展時只需要對于系統差異部分進行描述，而不是大段拷貝代碼。
4. tpl模板庫和sql-map機制等采用的是追加覆蓋策略。例如custom目錄下的ui.xml標簽庫文件并不是直接覆蓋系統根目錄下的ui.xml文件，而是按照標簽名進行細粒度的覆蓋。系統編譯時會自動檢查覆蓋標簽的所有參數要求和原標簽相兼容（例如允許增加參數而不允許減少參數），確保所有引用到原標簽的tpl代碼仍然有效。實際上整個witrix平臺多版本擴展機制的一個設計目標就是確保平臺主系統向各個分支產品的單向信息流動。在具體的表現上就是我們隨時可以拷貝平臺主系統覆蓋到分支產品的相應目錄，所有擴展實現與主系統實現保持分離狀態。當然為了保持設計的彈性，系統中也定義了開關參數用來有選擇的跳過一致性檢查。
Feedback
canonical：
實際上整個witrix平臺多版本擴展機制的一個設計目標就是確保平臺主系統向各個分支產品的單向信息流動。在具體的表現上就是我們隨時可以拷貝平臺主系統覆蓋到分支產品的相應目錄，所有擴展實現與主系統實現保持分離狀態
你說的這個分支版本是指不同的項目嗎？
按你的寫的，應該是主干版本通過擴展，自定義等手段，以達成項目客戶化的版本。如果是這樣，那么當主系統的元數據升級后是不能隨意覆蓋到項目版本的，需要按具體情況具體分析，能直接覆蓋的只能是低層的Framework
分支版本可以是不同的產品，不一定是同一產品的不同實施版本。在設計上的要點就是盡量允許主系統升級后可以隨意覆蓋項目版本，因為項目版本針對主版本的修改是以追加方式進行的，即并不直接修改任何主版本的文件，而是寫在獨立的文件中，平臺負責把custom內容和基礎版本內容融合。如果分支版本完全需要采用新的實現，平臺提供了完整的替換機制，同時可選擇是否校驗接口的兼容性。
其實我之前的想法也是和你一樣的。認為只要項目實施時以擴展方式，寫在獨立的文件中，這樣就能使核心升級時，不影響到項目，但事實真是這樣嗎？
后來我覺的，一個業務系統的升級，是需要劃分scope的，哪些升級，哪些不升級是需要選擇的，因為最終項目可運行版本是 (production core + Custom) 你升級了核心，就可能會影響到這個二元組的結果
比如一個流程，主版本定義 A->B，項目實施時，擴展這個流程A->B-C，主版本若升級后，變成A'->B'，雖然它未覆蓋項目實施擴展出來的那部分，但實際的運行過程已經變成A'->B'->C了。
沒有人認為核心對分支完全不影響，否則核心升級就沒有任何意義。只是升級是可選擇的，而且分支可以選擇整體覆蓋，即擴展后整個流程A->B->C都屬于分支