Spring的缺點有哪些--Ext擴展

http://www.iteye.com/topic/1131284

1.JavaTear2014 --   發表時間：2013-07-17   最後修改：2013-07-17 

Spring應用比較普遍,自己應該沒有什麼大問題,只不過就是愈來愈龐大了,複雜了! 

若是喜歡輕量級別的朋友,我在這裏推薦一個(總共也不過500k),它包含Ioc,orm,event,log,job等,已有項目採用這個工具進行開發的,性能還能夠! 

Blog:     http://blog.csdn.net/javatear/article/details/8994151

下載地址: http://pan.baidu.com/share/home?uk=2218126399

---------------

sharong --發表時間：2013-07-29   

不少互聯網高併發應用啓動一次要10分鐘以上，可是由於都是nginx配置的集羣，在前端感受不到 

------------------------------------

小te --   發表時間：2013-07-16   

魚言風語 寫道

不支持熱部署，是其爲數很少的較大的缺點

JRebel就支持Spring的熱部署，改個註解什麼的都不用重啓服務器。 

Eclipse Marketplace裏能夠在線裝，不過這貨是收費的，能夠試用十多天。 

***************************************

2.iceofst --   發表時間：2013-07-17   

Spring 確實可使應用程序鬆耦合，這沒有問題。可是DI爲咱們的帶來多大益處我不是特別清楚。 

作了幾個項目。項目裏面絕大部分類都在用Spring進行管理。不少人寫服務的時候都是思惟定式：接口+實現類+Spring bean。 

搞到後面，我本身都麻木了。最近一直在思考，Spring到底爲咱們帶來了什麼益處，咱們是否是正確的、按照框架提供者的初衷在用這個框架，而不是看到別人用我就用。 

我我的理解： 

在不改變架構的前提下，類和類之間的依賴關係是不會消除的。 

咱們能夠經過各類手段轉移類的依賴關係，甚至依賴的方向。 

DI就是一個很好的例子，他作了兩件事情：1.把類的依賴關係轉移到了框架進行管理，2.反轉依賴關係的方向，由框架提供依賴的對象而非本身去取。 

這樣作的好處是，使類之間的依賴具備很高的靈活性。咱們能夠很方便的切換類的實現，而調用方只用單純的面向接口編程。 

可是問題來了，咱們程序裏面，確實須要用到上述特性的場景有哪些？ 

好比： 

更易於測試。可是相比專門的測試框架（好比jmock）並無優點。 

粘合劑。確實方便了多個框架的整合，可是用代碼方式來整合也很簡單。 

你們是什麼想的，求指點。 

---------------------------------

小te--發表時間：2013-07-18  

我以爲Spring能夠分爲兩部分來看： 

1）IoC/DI/AOP 

2) 基於IoC/DI/AOP的集成了其餘優秀開源框架的一體化框架 

第一部分前面已經說了中心做用就是「解耦」。 

第二部分能夠橫向對比一下Ruby裏的Rails和PHP裏的Zend Framework，都有相似的框架，這些框架之間都有相互借鑑。 

區別就是其它語言的相似框架都是從頭至尾本身搞的，而spring是個另類，本身自己的東西不多，都是集成別人的。這得益於java開源世界裏資源豐富，沒有必要重複發明輪子。Ruby on Rails的插件也不少，不過這個是反的，別人是針對Rails來寫插件，Spring則是主動把別的已有框架適配進來，這一點上Spring更高明些。 

另外一個區別是其它web服務器端語言通常都是動態的，動態語言的特色是在運行時能夠改變自身結構，因此實現插件化很是容易。而Java是靜態或者說是半動態的，在Java裏要實現相似於動態語言可插拔的特性就要用Spring這樣的IoC/AOP框架，由於JDK自己並不提供這樣的功能，Spring至關因而對虛擬機進行了hack。 

回過來再說前面的解耦。 

對象之間有一種關係叫依賴關係，就是一個類裏調另外一個類，另外一個類當參數傳進去。 

爲了下降兩個類之間的耦合，咱們一般會引入接口，一個類去調另外一個類的接口，而不直接調這個類，就是所謂的針對接口編程。 

固然使用接口是有前提的，就是這部分功能會變更會擴展時纔有必要引入接口，我總不能爲了低耦合搞得系統處處都是接口吧，過分設計是沒有必要的。 

問題來了，若是隻是一個普通的類沒有設計接口怎麼來擴展加新功能，並且這個類仍是第三方的只有架包沒有源碼。這時用Spring的DI就簡單了，你只須要新寫一個類繼承原來的類，而後修改一下xml裏的bean的配置就把原來的類替換掉了。（固然你只能訪問父類裏public和protected的數據和方法，private的操做不了） 

AOP也是同樣的，用JDK標準的作法你只能攔截實現了指定接口的類，而用了Spring就不同了，一個普通的類你也能夠攔截，用不着接口。AOP典型運用場景好比事物、日誌，把規則配上就有了，用不着寫程序了。 

再說一下你說的另外一個問題，就是在service層寫大量的接口。咱們知道接口的做用是能夠替換成不一樣的實現，但實際上對於大多數系統service層可能就一種實現，之後也不會替換成其它實現了。那有沒有必要寫接口，我認爲仍然是有必要的。由於service也就是俗稱的業務邏輯層表達了這個系統的行爲，就是說service肯定以後你這個系統能作哪些事情就肯定了，因此service的接口是須要認真設計並且也不該該隨便修改的。所以service應該被抽取成接口，並且應該加上詳盡的註釋，service方法的命名能夠略長要能清楚的表達這一功能邏輯的意思。 

與之相對應的是DAO層的接口問題。搞java的操做數據庫都習慣用DAO，DAO的全稱是Data Access Object，業務層調用DAO來訪問系統數據。典型的DAO設計模式有一個工廠類、一個接口、一個實現類，網上能找到的示例通常也都是這個樣子的。可是，當你使用任何一種設計模式最好是能搞清楚使用場景和它最初的來源。在java裏引入DAO最初是爲了解決數據庫遷移問題，有了DAO就能夠用替換實現類的方式在不一樣數據庫之間切換，當時搞java的那幫人甚至yy有了DAO我之後能夠不用數據庫換成用文件來存數據。因此看清楚了，解決數據庫遷移問題，能夠在不一樣數據庫之間切換，這正是hibernate乾的事情！因此若是你有用hibernate沒有手寫SQL就沒有必要給DAO加接口，若是你有寫SQL但確定不會換數據庫也沒有必要給DAO加接口，即使是你有寫SQL之後也可能會更換數據庫那也沒有必要如今就給DAO加接口，由於換的時候再加是同樣的。 

因此咱們對系統進行設計和架構必定是基於場景的。系統設計的一個基本技巧是分析出對業務來講哪些是變量哪些是固定值，一個系統不可能任意靈活，過分設計一樣會讓系統變得複雜難以維護。基於分析，基於框架，留出必要的擴展就夠了。 

---------------------------

低下頭是人間 --   發表時間：2013-07-28   最後修改：2013-07-28 

指出幾個問題： 

1. 動態語言的特性是運行時能夠改變某個類的結構，好比增長一個方法 

Spring並無使java具有此特性，它也沒有對jvm進行任何hack 

2. SpringAOP並無實現針對類進行代理的功能，它只是使得攔截變得可配置而已。針對類進行代理這一功能是經過cglib實現的。 

3. java引入dao是爲了解決java類與數據庫表的映射問題，與數據庫遷移一點關係都沒有。 

********************************************

3. zh_harry -- 發表時間：2013-07-19   

witcheryne 寫道

說幾個Spring缺點: 

1. Spring 就不該該出來，那時候我就會應爲EJB太麻煩，不會走Java這條路。 

2. Spring 爲何沒有歸到 java 擴展包中，而且成爲java默認配置。每次建項目都要配。 

3. Spring ORM太邪惡了，我已經快忘了Hibernate中的方法如何使用。 

4. Spring AOP平時不多用，通常配置好一次不會再動，面試老是有人問，出了知道這是面向切面，其餘的沒印象。 

5. Spring 爲何要支持JRuby, Groovy之類的腳本。這樣我就能夠直接使用JRuby或者Groovy做爲上層語言，而不是Java中嵌入這類腳本。 

Spring缺點太多了，樓下繼續補充.

兄弟你太邪惡了

---------------------------------------

4.Spring Security能夠略過. Apache Shiro +1 

去年年末打算重構項目的權限部分，Spring Security & Apache Shiro 同步研究,  最終被Apache Shiro的簡單征服了. 

如今用的很舒服. 

-----------------------

小te--發表時間：2013-07-22   最後修改：2013-07-23 

Spring Security比較雞肋，由於Spring Security是由acegi轉過來的，跟spring親生的Spring MVC能夠說是兩個級別的東西。 

國內的權限系統一般會比較複雜，而基於Spring Security稍微複雜一點兒的權限系統你就須要本身擴展一堆東西。擴展一堆東西就爲了複用一點點功能，跟本身重頭實現一個權限系統基本也相差無幾了。並且Spring Security的API接口設計得一點兒也不友好，文檔也不行，不少時候你不得不去看源碼。惟一的好處就是由於是基於Spring的，因此你確實能夠基於它擴展出任意複雜的權限系統來。 

我仍是五年前用的，當時Spring剛發佈3.0版本，Spring Security剛從acegi更名過來。那時候java領域實在是沒有比Spring Security好點兒的權限系統了，因此也不得不用它。