先談下這個(gè)解決方案的背景:
假設(shè)一個(gè)公司的產(chǎn)品遵循的是先有基礎(chǔ)平臺(tái),然后在此平臺(tái)上構(gòu)建不同的產(chǎn)品,最后每一個(gè)產(chǎn)品被實(shí)施到特定的項(xiàng)目,那么，他們就構(gòu)成了一種層次化的結(jié)構(gòu).每一個(gè)層次,需要覆蓋一些上一層次的配置或者創(chuàng)建新的配置,如何分割層次間的影響從而保證層次間的獨(dú)立性，是一個(gè)挑戰(zhàn).
任意層次,可能有多個(gè)模塊或者組件構(gòu)成，不同的組件間，配置的類型可能一樣，但是配置的數(shù)據(jù)不一樣,那么,如果在配置某個(gè)模塊時(shí)，不比考慮其他模塊的配置情況，那么這個(gè)模塊就擁有開(kāi)發(fā)時(shí)的獨(dú)立性,當(dāng)組件被集成到同一層次部署運(yùn)行時(shí)，配置的合并和重組是一個(gè)問(wèn)題,并且，組件間可能存在依賴關(guān)系,這種依賴關(guān)系同時(shí)產(chǎn)生了依賴組件間配置加載的優(yōu)先級(jí)問(wèn)題.
成熟的軟件，一般不會(huì)直接將第三方的軟件集成，而是將其封裝后在納入進(jìn)來(lái),第三方組件的配置往往不具備配置的層次化或者模塊獨(dú)立性.在設(shè)計(jì)第三方組件的集成策略時(shí)，需要考慮使其擁有上述兩種能力.
解決上述問(wèn)題，方式有很多種,我們談?wù)摫容^容易實(shí)現(xiàn)的一種.
這種解決方案的基本思路如下:
首先，設(shè)計(jì)一個(gè)特定的擴(kuò)展名稱的配置文件(模塊配置索引文件,MCIF,xml格式)，此配置文件面向的是組件級(jí)別，即每個(gè)組件定義自己的MCIF.MCIF中定義若干配置類別,即名稱空間,每一個(gè)名稱空間負(fù)責(zé)完成一類配置，一般,一個(gè)名稱空間對(duì)應(yīng)一個(gè)配置獲取接口.這個(gè)名稱空間中僅僅配置所關(guān)注的配置的文件的相對(duì)位置(相對(duì)此MCIF),這樣，最大化的減少了不同配置文件格式對(duì)MCIF的影響.
每一個(gè)MCIF的根元素?fù)碛幸粋€(gè)parent屬性,指向了上一層次,同一層次的MCIF的parent屬性都相同.通過(guò)parent屬性，配置的層次化就不是問(wèn)題了.
MCIF有兩個(gè)特殊的名稱空間:
1.register 定義了所支持的名稱空間及其對(duì)應(yīng)的配置解析器,這樣,此配置框架就可以允許對(duì)名稱空間進(jìn)行擴(kuò)展.
2.depends 定義了同一層次的模塊間的依賴關(guān)系,這個(gè)是可選的，如果沒(méi)有實(shí)現(xiàn)或者配置，同一層次的module即為平行的.
當(dāng)系統(tǒng)啟動(dòng)時(shí),掃描所有的MCIF,并根據(jù)parent屬性解析出一個(gè)層次關(guān)系,對(duì)每一個(gè)層次下module,參考相應(yīng)的depends設(shè)置定義出一個(gè)依賴關(guān)系.
當(dāng)請(qǐng)求某特定的配置時(shí),根據(jù)上述的兩個(gè)關(guān)系完成配置的組合，并返回給使用者.
公司最近的重構(gòu)中，基于這個(gè)思想開(kāi)發(fā)的配置小框架，很好完成了多層次，多組件的配置覆蓋問(wèn)題,配置相對(duì)以前更清晰、簡(jiǎn)單，配置過(guò)程中的關(guān)注點(diǎn)大大減少.