【賽迪網技術社區整理】近一直在忙于學習業務系統和學習c++，對技術框架已經疏于了解。恰好一同事在我項目里使用了spring,并帶了些問題，所以決定看看Spring技術，針對我同事帶來的這些問題與大家討論。

　　主要是些負面的體會。

　　一。Spring的xml配置很不好。xml濫用程度已經泛濫成災了。要知道程序員習慣，歡迎的還是看代碼。當要看一個業務邏輯時發現竟然先要去看它的父類，然后看爺爺類，然后再看太爺爺類，發現還需要找Spring配置去找另外一個類，而這個類ref了另外一個類時，肯定哐當暈倒。無論是初學語言，還是對技術深入了解的高手，或者還是因為項目緊急從別的地方抽掉過來的其他成員。簡單的代碼和配置都是合適的（像我這樣用了好幾年的java的人已經有點不愛看xml配置）。

　　二。Spring的配置方式不支持開發模式。每次修改Spring配置，總是需要重啟動。一些大項目啟動是非常耗時的。相反一些別的小的第三方配置開發包可以支持開發模式。另外，我覺得Sping也不太可能支持開發模式，這在下面一點會說到

　　三。直覺上Spring管的太多。對于很多框架或者第三方lib來說，往往專著于完成系統的某一方面。如Hibernate專著于O/R Mapping,EJB專著于分布，事務，規則引擎專著于解釋規則，執行運算等。Spring做的太多使其有啥都做不好的嫌疑，當然這還不是主要的負面因素，而是他干擾了業務系統。他對對象進行管理有可能會讓某些用戶用Spring管理業務對象。這有可能帶來負面結果的。如一些情況：Struts的MVC被Spring接管，業務邏輯又被Spring接管。一個新手很難看懂代碼。了解代碼的時候總會遇到“黑洞”。又如上面所說的開發模式，因為業務對象的互相依賴，"重新啟動業務對象"是很復雜的一件事情，Spring也不可能做到這一點。除非你的業務對象屈服于Spring的架構，這又和使用Spring初衷違背了。再如，業務對象的復雜性，核心性決定了Spring難以管理好它，也沒有必要多此一舉.

　　四。適配器成災。Spring為了管理好第三方包，只好做些適配器。以方便管理。當然，有些第三方包很簡單，不需要做，比如我看到javaresearch.org剛有的一篇文章是在Spring中使用定時器。但是某些復雜的第三方包或者框架就有問題了，得寫適配器。如接管某web mvc框架。又如剛才所說的定時器lib，本生功能齊備的定時器lib就有自己的配置，你要去Spring去管理它。只能寫個適配器，在適配器中使用定時器lib提供的配置文件。