不過隨著業務的擴充套件，你就會發現jdbc建立一個連線居然要幾百毫秒，而執行一個普通的SQL僅僅需要幾毫秒。
這麼重量級的資源建立了就釋放了不合適，得找個容器存起來，誰要就來取，不用了就還給容器，畢竟容器裡的借取比建立一個連線要快的多。
這樣的容器叫做資料連線池。
小日子繼續過，業務也越做越大，慢慢地你就發現了：這jdbc的介面也太粗暴了，有一大半的程式碼在往bean裡塞資料，下標還是從1開始的。
這時候你就會想，要不獨立一層，專門處理把jdbc讀取出來的資料塞進bean裡吧。
這一層就是DAO，data access object，比較出名的框架就是myBatis。
公司越做越大，你也在不斷嘗試新鮮的技術，並且在其中的一個專案上實踐了敏捷，積極擁抱變化。
不久後你就發現了，一次迭代中多出的一個欄位，你的SQL模板就去同步，然後你望著專案裡指數級增長的SQL模板，心裡一陣陣發慌：要是有個框架，只需要管理bean之間的關係，就可以生成常用的CRUD語句。這就是ORM框架，比較出名的就是Hibernate，其中的大部分介面被JSR吸納，成為JPA標準。
漸漸地，使用公司產品的客戶越來越多，但是一部分客戶希望系統通知通過簡訊來推送，另一部分希望通過郵件。除此之外，大家對剩下的功能沒有任何分歧。
雖然在編寫程式碼時，你已經在這裡對通知的推送做了介面隔離，但是因為這個介面的引用指向的一個new關鍵字建立物件，所以程式的行為在編譯時就已經確定了。
為了響應另一部分客戶的需求，你不得不在打包前，去修改程式碼。
這時候你就在想：如果程式的行為可以通過一些配置在執行時才確定，或許可以改善現在的處境。
這種把物件的例項化交給容器（執行中的程式）而不是另一個物件（硬編碼的程式碼）的設計思想叫控制反轉（IOC），這就是Spring所做的事情。