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