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