一直在看Spring的相关课程，光关于Spring这个主题的课程，看了也不少了。但是，也就是能够学会一些套路，在日常的开发过程中，照葫芦画瓢的使用。一直没有对Spring有一个深刻的理解。
今天突然，在看了秦疆的课程之后，突然对于Spring有了一些独特的理解。虽然，秦疆讲的也不错，但是，也难免落入窠臼之中，惯于使用以前的老师们的授课套路来讲。
首先，在Spring之前，我们的开发面临什么样的问题
- 以前我们的开发中，Controller中使用Service层时，需要自己手动去new。这是问题吗，这其实就不是问题。如果连手动去new都懒得做，就不要去做程序员了。
- 如果后续维护过程中，需要替换原来的Service层，就要修改Controller中的new代码的地方。这不利于扩展，这看起来好像是个问题，注意，是好像。其实，我到目前为止都没有这样做过一次。这仍然没有说服力。
从上面的场景入手，我宁愿返璞归真，使用硬编码的方式来开发代码。所以，我认为这些都没有说到点子上。如果要真正明白我们开发面临的困难，其实，我们不妨从Spring帮我们做了什么事情来反推。
其次，有了Spring之后，我们的开发变成了什么样
众所周知，大家现在使用的SSM，Spring Boot的那样的开发就是。
最后，Spring框架的原理是什么，或者说，Spring到底帮我们做了什么事情
这里有两个关键词：IoC （对象创建的控制权从程序猿手中反转给了容器）、DI（注入对象依赖的其他组件）。
上面的关键词，我写了自己的理解阐述。
- Spring首先是一个IoC容器。那么，这个Spring就相当于是一个玻璃罐子。在这个罐子里，我们可以放入各种各样的Bean（豆子）。这里，涉及到一个问题，就是Bean从哪里来。也就是说，Spring解决了一个对象创建的问题。Spring是如何解决这个对象创建的事情呢，就是从我们的配置文件的信息中，获取到他创建一个类对象所需要的的信息，然后存储在容器之中。
- 我们使用这些Bean，直接拿来用即可，因为罐子中保存了这些Bean。但是，我们实际中会这样做吗。当然不会啦。因为，都是从Spring容器中，直接获取对象的话，这不就是脱裤子放屁嘛，所以，IoC这一步也是为了接下来更好的使用做准备的。大规模的使用中，我们都是用依赖注入的的方式来使用这些Bean，其实，这解决的是一个类组织的问题。
所以，通过上面的分析就是，Spring 通过配置文件创建对象，并保存在IoC容器中，然后，在通过DI依赖注入的方式，让我们去组织和使用容器中创建的对象。前半部分，是Spring容器帮我们做的事情，后半部分，需要我们程序猿去做。
那我们仔细看看这句话Spring 通过配置文件创建对象，并保存在IoC容器中，说白了，能够通过字符串去动态获取对象，也只能使用Java的反射技术了。所以，我们就能够从反射技术去反推Spring能玩出什么新花招。
- 反射技术通过字符串动态生成一个对象，Spring基于这个特性实现配置创建对象；
- 反射技术通过字符串调用方法setter，Spring基于这个特性实现配置对象的属性赋值；
- 反射技术通过字符串调用构造方法，Spring基于这个特性实现配置对象的构造方法创建；
还有很多的花样和玩法，总而言之，从反射技术去理解Spring的配置，Spring就是创建了对象，并把对象能够按照配置组织起来。那这对于我们有啥好处呢？其实，也没有什么好处。反倒显得有些臃肿。我们跳过这个抓耳挠腮寻找好处的环节，来说Spring的AOP。
Spring AOP
Spring利用Java的动态代理的技术实现了面向切面编程。就是从方法中通用的一些逻辑，操作抽离出来做一个统一的处理调用。这相当于Spring给我们一个AOP的一个标准实现，让我们来解决相对应的场景，这还是不错的。就拿事务而言，我们就要用容器中管理的对象，如果没有容器，我们当然也是可以实现的。这不过提供了一点便捷。我们再说，Mybatis的通过接口调用这一步，通过动态代理Mybatis生成了Mapper的实现类。我们真正去调用的话，就需要自己去手动调用。也是可以实现的，但是就没有那么便捷了。这里或许能够体现一点Spring容器的好处吧。
这样梳理下来，我发现，貌似在我们的日常开发中，并不能体会到Spring容器的好处。甚至是增加了复杂度和臃肿。从流程上来看，Spring 相当于是一个中间件，相当于是一个代码的协作规范。规范的坏处是什么，就是缺少了灵活性，同时也牺牲了简单性。但是，规范带来的好处是解耦，以及让更多更多的人和组织能够参与进来，方便代码、组件的复用。也就是说，以前大家都是各自为政，最后需要协作的时候，又各有不同，无法顺畅协作。有了Spring容器之后呢，大家就都面向Spring“规范”编程。这样就能避免协作困难的问题了。所以，课程里简单的举例对象创建由Spring容器管理，并不能体现Spring的好处，反而显得怪异。真正的好处，是要放在更多的团队协作上来说。
