計算機軟件水平考試：開源框架思索[2]

　　雖然，我們一直強調整體大于單個的總和，但是如何將單個“個體”正確的組合成發(fā)揮更大效應的“整體”卻并非易事。因為這些單獨的框架都由不同的團隊開發(fā)，框架與框架之間存在天然的阻抗，這種框架和框架之間的“代溝”需要額外配置和編碼才能彌合。
　　每個框架都擁有自己的配置文件，框架的整合經常帶來配置的災難，如將Spring和Struts整合時，不僅Struts本身的配置文件一個不能少，在Spring中還需要每個Action提供配置信息，而且兩者需要遵守一定的契約。
　　相互搭配的框架和框架之間經常會出現(xiàn)相似的或重復的功能，如何取舍，如何使用往往讓開發(fā)者們?yōu)殡y。如Spring本身提供了AOP方法返回結果的緩存功能，而Hibernate本身也提供二級緩存，究竟兩者都使用呢，還是擇一而從？往往中間又會引出很多爭論。 mda.com 　
　　框架整合的問題已經日益突出，我們可以在各開源或社區(qū)發(fā)現(xiàn)大量有關討論的主題。
　　目前也出現(xiàn)了一些試圖解決的框架整合問題的開源項目，如國外的AppFuse，國內的SpringSide，為框架的整合提供了專業(yè)的指導。但是并沒有很好的解決現(xiàn)實開發(fā)中的實際需要。這些整合框架為了增加通用性，網都撒得太大，導致整合框架本身象一個龐然大物，讓人望而生畏，定制性和靈巧性上都存在不足，降低了它們的實用性，所以這些整合性的開源項目往往降格為指導性的實例。
　　升級的困擾
　　活躍的框架每天都在升級改造，豐富功能。其次由于開源框架在一定程度上存在隨意性，往往導致框架在實際使用后，發(fā)現(xiàn)大量隱含的Bug，所以有時對某個框架的升級變得不可避免。開源框架比之Sun正規(guī)的規(guī)范有著更加靈活的升級方式，高低版本不兼容的問題已經成為司空見慣的事情。如著名的Hibernate，其3.0版本和2.0版本的包名都發(fā)生了徹底的變化，剛發(fā)布的Acegi和低版本也存在很大的差異，無法兼容。
　　一個整合性的框架由多個出自于不同團隊的框架組成，整合框架在這些組合框架之上高位運行，底層框架的升級變化就造成了組合框架水漲船高的局面，整合框架脆弱的穩(wěn)定性很容易被打破。
　　組合框架的升級還直接帶來了開發(fā)團隊學習的壓力，為了熟悉框架新功能和改進，在開發(fā)工作之余，他們不得不努力壓榨自己的業(yè)余時間不斷地充電學習�？偸悄硞�框架新功能學習還未完成，另一個框架的新版本又在一陣歡呼聲中閃亮登場，讓開發(fā)人員發(fā)現(xiàn)自己所有的努力只是一場騎牛追馬游戲。
　　3、開發(fā)者如何走出迷局
　　框架的爆炸性增長和技術更替一日千里的速度，讓剛剛從傳統(tǒng)J2EE迷局中走出來的開發(fā)者重新墮入了新的困境之中。有許多切身體驗的開發(fā)者在網上大倒苦水，甚至有許多聲音在吶喊，希望重新回到JSP+JavaBean＋JDBC那個純真的年代中去。
　　框架的們本想還軟件開發(fā)一個清新美滿的世界，不想個體性的良性企盼變成了一種整體性的混亂紛爭。在紛繁復雜的開源世界如何走出迷局和困境，把握自己技術航船的方向，是每個開發(fā)者們冥思遐想的事情。
　　重點學習 觸類旁通
　　每個人的時間是有限的，對于周期緊，進度急，加班趕的開發(fā)者來說更加如此，使得開發(fā)者不可能 “識遍天下字，讀盡人間書”逐個學習框架。選擇好適合自己、適合項目的框架進行重點學習尤為重要。不但要掌握技術細節(jié)，更要理解框架的原理和思想，這樣在接觸相關框架時，我們才能觸類旁通，慧眼識真。
　　如果你深入理解了Struts框架的MVC的原理和思想，在接觸Tapestry，Spring MVC等框架時，你會發(fā)現(xiàn)兩者只是形上的區(qū)別，而非質上的差異，即使因現(xiàn)實需要確實要轉換框架時，也可以輕松平滑地過渡。

轉帖于：軟件水平考試_考試吧