1. Spring的配置臃腫
    我的專案組在開發一個企業級應用時，使用了依賴注入框架。這個專案中，有1500多個類，並且分散在超過11個的模組裡。
以我在實際開發中的經驗，我們創建出的service物件應該少於依賴他們的其他物件。如果我們使用了Spring框架，當我們建立需要依賴100個service物件的1000個action物件時，這就意味者我們要對這1000個bean做配置工作。
如果action的數量還在不斷增加，這項工作將變得更加糟糕。我們試圖重構一些東西、而又不願破壞已有的程式碼，就必須加倍小心。
你或許想到了通過型別（byType）來自動繫結，哦？這或許不是一個壞主意。可是，為什麼不通過名稱(byName)來自動繫結呢？可是如果我們對不同的物件做配置就有不同的名稱，這聽上去很容易讓人糊塗，那樣的話，我猜你又得在辦公室裡度過漫漫長夜了。

2. XML檔案配置痛苦

     XML配置痛苦，這個痛苦不是說編寫它有多複雜，更多是指其維護性。
如果你有1000個action，你需要對在配置中放置什麼和如何放置很清楚，你需要有隻鷹般銳利的眼睛，你必須不能忘記在改動XML配置時使用工具來查詢和替換，否則，這個應用程式會在產品化的時候崩潰。

3. 如果使用XML配置，你將弱化Java強型別檢查
    當你開始使用XML配置的時候，你將弱化Java的強大。
    當你幸運地發現注入到bean裡的這個物件不是這個bean所需要的，但你必須等待下去直到Spring容器開始啟動並且檢查依賴關係。在這個時候，你該意識到你犯了個愚蠢的錯誤。哎！
一些配置不使用XML，而使用Java類，在Guice裡，你可以使用module。如果我們想要靈活性，我們仍然可以通過分離業務邏輯包到另外的包中來達到這點，並且在核心包中，你只需使用Class.forname(”the module class”)。這就是全部所在！

4. Spring不是輕量級的容器

    不幸地是，Spring不再是輕量級容器。現在，Spring的效能不再是最快的了，已經有很多效能更好的輕量級容器出現了。

5. Spring是一個希望我們構建鬆耦合程式的容器
    Spring是一個只是希望我們使用鬆耦合技術的容器，Spring沒有真正地更多關注緊耦合。我非常確定，一旦我們使用除了spring-core.jar的Spring包，這將意味著我們的程式不能離開Spring存活。