不过随着业务的扩展，你就会发现jdbc建立一个连接居然要几百毫秒，而执行一个普通的SQL仅仅需要几毫秒。
这么重量级的资源建立了就释放了不合适，得找个容器存起来，谁要就来取，不用了就还给容器，毕竟容器里的借取比建立一个连接要快的多。
这样的容器叫做数据连接池。
小日子继续过，业务也越做越大，慢慢地你就发现了：这jdbc的接口也太粗暴了，有一大半的代码在往bean里塞数据，下标还是从1开始的。
这时候你就会想，要不独立一层，专门处理把jdbc读取出来的数据塞进bean里吧。
这一层就是DAO，data access object，比较出名的框架就是myBatis。
公司越做越大，你也在不断尝试新鲜的技术，并且在其中的一个项目上实践了敏捷，积极拥抱变化。
不久后你就发现了，一次迭代中多出的一个字段，你的SQL模板就去同步，然后你望着项目里指数级增长的SQL模板，心里一阵阵发慌：要是有个框架，只需要管理bean之间的关系，就可以生成常用的CRUD语句。这就是ORM框架，比较出名的就是Hibernate，其中的大部分接口被JSR吸纳，成为JPA标准。
渐渐地，使用公司产品的客户越来越多，但是一部分客户希望系统通知通过短信来推送，另一部分希望通过邮件。除此之外，大家对剩下的功能没有任何分歧。
虽然在编写代码时，你已经在这里对通知的推送做了接口隔离，但是因为这个接口的引用指向的一个new关键字创建对象，所以程序的行为在编译时就已经确定了。
为了响应另一部分客户的需求，你不得不在打包前，去修改代码。
这时候你就在想：如果程序的行为可以通过一些配置在运行时才确定，或许可以改善现在的处境。
这种把对象的实例化交给容器（运行中的程序）而不是另一个对象（硬编码的代码）的设计思想叫控制反转（IOC），这就是Spring所做的事情。