在学习java之前就老听说这框架，那框架，牛逼得可以上天了，对于个门外汉来说，只听雷声，没见雨点的，你到底牛在哪里？有多牛？正如标题，我所认为的所有的牛逼全部体现在能解放多少劳动力的标准上，可能这个标准有些畸形，畸形得感觉编程只需要像用社交软件泡妹一样，点点就可以了，哪来那么多的前奏？言归正传，在没有spring的思想前，我的编程是这样玩的，java工程为：Action,Dao,DaoImpl,Pojo,ServiceDao,ServiceImpl,这几个代码层可以实现一般的curd,通常是一个功能对应一个Dao,DaoImpl，Service,ServiceImpl这样做，优点当然是显然易见的，逻辑比较清晰，查找问题也比较简单，但是有一个致命的弱点：
场景：原始的Dao层或DaoImpl层的里面的方法发生了改变，那就意味着后面只要是调用该Dao层所有Service层里面的代码都要随着改变，而现实中，又不知道是哪些Serivce调用了它，只能以打补丁的方法去填补，问题来了：如果有三百个service有多处调用了该Dao层，怎么解？蒙蔽的无限循环。。。。。
改造一：面向接口编程方式改造（使用者只看接口，不管实现类，实现类交给spring的BeanFactory去创建）
这样写有什么好处？
service层要调用Dao层的实现类时，不需要new对象了，去BeanFactory里取即可，要修改Dao层实现类，也只需要改BeanFactory就行了，没有必要修改调用者。这样从源头来管理，只需要改源头的代码即可，大大减少了维护成本。
但这里有一个问题：如果这个BeanFactory里面的方法越来越多，又该怎么样去管理呢？在改造一的基础上升级改造：
改造二：通过泛型来减少代码量，再通过配置文件来反射来需要加载的类来创建对象，service层需要创建Dao层对象时，只需要传相应的key,即可加载相应的类到内存中，来创建对象。代码实现如下：
配置文件：
BeanFactory静态加载：
再通过service传入的key,从properties中取出相对应实现类来创建对象，再以返回给service,因为不知道要调用哪个实现类来new对象，所以在定义方法时，返回值只能给泛型。代码实现如下：
如此，当Dao层实现类或Service发生改变时,我们只需要去维护properties里面的配置就行了。而且在外部调用时，我们只需要写上properties对应的key值（说白了，该类在properties的一个映射的外号），外部调用代码实现如下：
以上通过两次升级，大大提高了效率，减少了维护成本，这只是一个框架的引入，是一种工厂来创建对象的思想，后期还会利用框架来对现有的这种来进行改造。