【譯者按】這幾天,TSS上的一篇熱文,討論者眾多,特翻譯,水平有限,望多指正。
原文地址:http://gorif.wordpress.com/2007/07/01/5-reasons-why-i-think-i-will-not-use-spring/
我不愿使用Spring有幾個理由:
1. Spring的配置臃腫
我的項(xiàng)目組在開發(fā)一個企業(yè)級應(yīng)用時,使用了依賴注入框架。這個項(xiàng)目中,有1500多個類,并且分散在超過11個的模塊里。
以我在實(shí)際開發(fā)中的經(jīng)驗(yàn),我們創(chuàng)建出的service對象應(yīng)該少于依賴他們的其他對象。如果我們使用了Spring框架,當(dāng)我們創(chuàng)建需要依賴100個service對象的1000個action對象時,這就意味者我們要對這1000個bean做配置工作。
如果action的數(shù)量還在不斷增加,這項(xiàng)工作將變得更加糟糕。我們試圖重構(gòu)一些東西、而又不愿破壞已有的代碼,就必須加倍小心。
你或許想到了通過類型(byType)來自動綁定,哦?這或許不是一個壞主意。可是,為什么不通過名稱(byName)來自動綁定呢?可是如果我們對不同的對象做配置就有不同的名稱,這聽上去很容易讓人糊涂,那樣的話,我猜你又得在辦公室里度過漫漫長夜了。
2. XML文件配置痛苦
XML配置痛苦,這個痛苦不是說編寫它有多復(fù)雜,更多是指其維護(hù)性。
如果你有1000個action,你需要對在配置中放置什么和如何放置很清楚,你需要有只鷹般銳利的眼睛,你必須不能忘記在改動XML配置時使用工具來查找和替換,否則,這個應(yīng)用程序會在產(chǎn)品化的時候崩潰。
3. 如果使用XML配置,你將弱化Java強(qiáng)類型檢查
當(dāng)你開始使用XML配置的時候,你將弱化Java的強(qiáng)大。
當(dāng)你幸運(yùn)地發(fā)現(xiàn)注入到bean里的這個對象不是這個bean所需要的,但你必須等待下去直到Spring容器開始啟動并且檢查依賴關(guān)系。在這個時候,你該意識到你犯了個愚蠢的錯誤。哎!
一些配置不使用XML,而使用Java類,在Guice里,你可以使用module。如果我們想要靈活性,我們?nèi)匀豢梢酝ㄟ^分離業(yè)務(wù)邏輯包到另外的包中來達(dá)到這點(diǎn),并且在核心包中,你只需使用Class.forname(”the module class”)。這就是全部所在!
4. Spring不是輕量級的容器
不幸地是,Spring不再是輕量級容器。現(xiàn)在,Spring的性能不再是最快的了,已經(jīng)有很多性能更好的輕量級容器出現(xiàn)了。
5. Spring是一個希望我們構(gòu)建松耦合程序的容器
Spring是一個只是希望我們使用松耦合技術(shù)的容器,Spring沒有真正地更多關(guān)注緊耦合。我非常確定,一旦我們使用除了spring-core.jar的Spring包,這將意味著我們的程序不能離開Spring存活。
原文地址:http://gorif.wordpress.com/2007/07/01/5-reasons-why-i-think-i-will-not-use-spring/
我不愿使用Spring有幾個理由:
1. Spring的配置臃腫
我的項(xiàng)目組在開發(fā)一個企業(yè)級應(yīng)用時,使用了依賴注入框架。這個項(xiàng)目中,有1500多個類,并且分散在超過11個的模塊里。
以我在實(shí)際開發(fā)中的經(jīng)驗(yàn),我們創(chuàng)建出的service對象應(yīng)該少于依賴他們的其他對象。如果我們使用了Spring框架,當(dāng)我們創(chuàng)建需要依賴100個service對象的1000個action對象時,這就意味者我們要對這1000個bean做配置工作。
如果action的數(shù)量還在不斷增加,這項(xiàng)工作將變得更加糟糕。我們試圖重構(gòu)一些東西、而又不愿破壞已有的代碼,就必須加倍小心。
你或許想到了通過類型(byType)來自動綁定,哦?這或許不是一個壞主意。可是,為什么不通過名稱(byName)來自動綁定呢?可是如果我們對不同的對象做配置就有不同的名稱,這聽上去很容易讓人糊涂,那樣的話,我猜你又得在辦公室里度過漫漫長夜了。
2. XML文件配置痛苦
XML配置痛苦,這個痛苦不是說編寫它有多復(fù)雜,更多是指其維護(hù)性。
如果你有1000個action,你需要對在配置中放置什么和如何放置很清楚,你需要有只鷹般銳利的眼睛,你必須不能忘記在改動XML配置時使用工具來查找和替換,否則,這個應(yīng)用程序會在產(chǎn)品化的時候崩潰。
3. 如果使用XML配置,你將弱化Java強(qiáng)類型檢查
當(dāng)你開始使用XML配置的時候,你將弱化Java的強(qiáng)大。
當(dāng)你幸運(yùn)地發(fā)現(xiàn)注入到bean里的這個對象不是這個bean所需要的,但你必須等待下去直到Spring容器開始啟動并且檢查依賴關(guān)系。在這個時候,你該意識到你犯了個愚蠢的錯誤。哎!
一些配置不使用XML,而使用Java類,在Guice里,你可以使用module。如果我們想要靈活性,我們?nèi)匀豢梢酝ㄟ^分離業(yè)務(wù)邏輯包到另外的包中來達(dá)到這點(diǎn),并且在核心包中,你只需使用Class.forname(”the module class”)。這就是全部所在!
4. Spring不是輕量級的容器
不幸地是,Spring不再是輕量級容器。現(xiàn)在,Spring的性能不再是最快的了,已經(jīng)有很多性能更好的輕量級容器出現(xiàn)了。
5. Spring是一個希望我們構(gòu)建松耦合程序的容器
Spring是一個只是希望我們使用松耦合技術(shù)的容器,Spring沒有真正地更多關(guān)注緊耦合。我非常確定,一旦我們使用除了spring-core.jar的Spring包,這將意味著我們的程序不能離開Spring存活。
|
|
歡迎大家訪問我的個人網(wǎng)站 萌萌的IT人
呵呵,謝啦。
很到位的見解!
@sea
呵呵,別激動啊,翻譯一下,就是希望大家討論啊。
二,用Spring不僅是為了DI.還有其提供的AOP,放心的事務(wù)管理等.
中肯的評價,呵呵。
@Sun
哲學(xué)觀點(diǎn)哦,^_^
@jeff
一、如果你的第900個配置,依賴于第300個,那是不是需要去找第300個呢?如何找?不累嗎?
二、嗯,同意!對AOP的強(qiáng)大支持,是Spring出彩的地方。
建議:1.一般而言,大家有沒有遇到在一個模塊就有1000個action?有,說明你的設(shè)計(jì)有問題
2.Spring支持XML的import,extends.大大簡化每個XML的重量。
3.Spring弱化類型檢查,這個是必然的,XML嘛,Spring也在關(guān)注非XML的應(yīng)用。
4.有論點(diǎn)無論居。。。
5.不知所云。沒有論據(jù)。搞不懂。
所以這人在吹牛。我的觀點(diǎn):我一向都給哪些說Spring不好的人講:Spring真的很爛,不要用了
哈哈,可以理解為什么這篇在TSS上大熱了。
http://gorif.wordpress.com/2007/07/01/5-reasons-why-i-think-i-will-not-use-spring/
原文處,也有很多回復(fù),呵呵,理越辯越明。
至于輕量不輕量的問題,InfoQ上有篇說得很好:http://www.infoq.com/cn/articles/ejb3-spring-compare,其中一個觀點(diǎn):“而對于Spring,也有同樣的問題,輕量級的內(nèi)核,也不意味著整個框架是輕量的,更不意味著基于Spring的整個應(yīng)用架構(gòu)是輕量的。”
至于最后一點(diǎn),我想作者的意思,大概是說離開spring-core.jar,想換另外一個框架或者實(shí)現(xiàn),得費(fèi)一番周折。
通常何為重用。重用的是我們的數(shù)據(jù)訪問,業(yè)務(wù)邏輯。這是是一個應(yīng)用中最核心的部分,Spring core封裝的就是IOC的主要api.我看了我的應(yīng)用我沒有發(fā)現(xiàn)我的業(yè)務(wù)邏輯包含任何的Spring的代碼,懷疑作者有沒有使用過Spring.沒有使用亂發(fā)飆,我很無語,我覺得,任何一個評價一個事物不好的人,應(yīng)該是深入了解這個事物的人,Rod之所以寫出j2ee without ejb,人家是有深刻使用ejb的經(jīng)驗(yàn)才批駁ejb,以至于ejb3做了很大的改進(jìn)。至于展現(xiàn),你使用spring MVC,當(dāng)然得為他埋單,你用Struts,webwork就不會耦合他們的api?
還是那句話,作者在吹牛。
http://www.infoq.com/cn/articles/ejb3-spring-compare
但是字的行間無不透露這個人是一個ejb使用者,而非spring使用者,
老話,沒有調(diào)查就沒有發(fā)言權(quán),你要搞死一個人,你就得深入了解他,然后抓他弱點(diǎn),一擊致命。可惜大多數(shù)發(fā)言人都是思考者。
呵呵,長炯兄,言之有理!
@滕偉
我同意你的“用誰,為誰埋單”的觀點(diǎn)。
一直有個疑問,在數(shù)據(jù)訪問這邊,如果一個DAO實(shí)現(xiàn)類擴(kuò)展了Spring中的HibernateDaoSupport,這樣,確實(shí)方便了很多,可是是不是和Spring綁定得太緊了?是不是使用Spring我們應(yīng)該更關(guān)注于它對業(yè)務(wù)邏輯的分離?當(dāng)然事務(wù)管理,它做得很好。
說得不對,請指正!
至于原文的作者Arif Rachim,他最新的一篇blog是:Google GUICE 1000% faster than Spring,http://gorif.wordpress.com/2007/07/05/google-guice-1000-faster-than-spring/
說吹牛,或許有點(diǎn)過了,:-)
至于O/R的好處就是讓你不在為寫一些繁雜的底層API而苦惱,使用不使用O/RMapping產(chǎn)品我覺得每個人都是很明白的,Spring對jdbc做了淺淺的封裝,我覺得這不是耦合,因?yàn)槟悴皇褂眠@樣的工具,通常你在項(xiàng)目里面也會對jdbc封裝。有為何不用?Hibernate也是如此,至于Spring對Hibernate的集成,我覺得也應(yīng)該沒有沒有在Code里面使用到Spring的代碼吧?沒有研究過。
至于HibernateDaoSupport,沒有寫過,不好給你回答。
我們又不是坐在研究室里面搞研究的頭頭鬧鬧,我們都是適用主義者,我們口號是,對我們有用的才是正確的~
呵呵,說得實(shí)在。