江苏龙网

  1. 主页 > 生活百科 > >

详细聊聊Spring核心思想

spring

犹记我当年初学 Spring 时，还需写一个个 XML 文件，当时心里不知所以然，跟着网上的步骤一个一个配置下来，配错一个看着 error 懵半天，不知所谓地瞎改到最后能跑就行，暗自感叹 tmd 这玩意真复杂 。
到后来用上 SpringBoot，看起来少了很多 XML 配置，心里暗暗高兴 。起初根据默认配置跑的很正常，后面到需要改动的时候，我都不知道从哪下手 。
稀里糊涂地在大部分时候也能用，但是遇到奇怪点的问题都得找老李帮忙解决 。
到后面发现还有 SpringCloud，微服务的时代来临了，我想不能再这般“犹抱琵琶半遮面”地使用 Spring 全家桶了 。
一时间就钻入各种 SpringCloud 细节源码中，希望能领悟框架真谛，最终无功而返且黯然伤神，再次感叹 tmd 这玩意真复杂 。
其间我已经意识到了是对 Spring 基础框架的不熟悉，导致很多封装点都不理解 。
毕竟 SpringCloud 是基于 SpringBoot，而 SpringBoot 是基于 Spring 。
于是乎我又回头重学 Spring，不再一来就是扎入各种细节中，我换了个策略，先从高纬角度总览 Spring，理解核心原理后再攻克各种分支脉路 。
于是我，我变强了 。
其实学任何东西都是一样，先要总览全貌再深入其中，等回过头之后再进行总结 。
这篇我打算用自己的理解来阐述下 Spring 的核心（思想），碍于个人表达能力可能有不对或啰嗦的地方，还请担待，如有错误恳请指出 。
抛开IOC、DI去想为什么要有Spring在初学 JAVA 时，我们理所当然得会写出这样的代码：
public class ServiceA {private ServiceB serviceB = new ServiceB();}我们把一些逻辑封装到 ServiceB 中，当 ServiceA 需用到这些逻辑时候，在 ServiceA 内部 new 个ServiceB  。
如果 ServiceB 封装的逻辑非常通用，还会有 ServiceC.....ServiceF等都需要依赖它，也就是说代码里面各个地方都需要 new 个ServiceB ，这样一来如果它的构造方法发生变化，你就要在所有用到它的地方进行代码修改 。
比如 ServiceB 实例的创建需要 ServiceC ，代码就改成这样：
public class ServiceA {private ServiceB serviceB = new ServiceB(new ServiceC());}确实有这个问题 。
但实际上如若我们封装通用的service 逻辑，没必要每次都 new 个实例，也就是说单例就够了，我们的系统只需要 new一个 ServiceB 供各个对象使用，就能解决这个问题 。
public class ServiceA {private ServiceB serviceB = ServiceB.getInstance();}public class ServiceB {private static ServiceB instance = new ServiceB(new ServiceC());private ServiceB(){}public static ServiceB getInstance(){return instance;}}看起来好像解决问题了，其实不然 。
当项目比较小时，例如大学的大作业，上面这个操作其实问题不大，但是一到企业级应用上来说就复杂了 。
因为涉及的逻辑多，封装的服务类也多，之间的依赖也复杂，代码中可能要有ServiceB1、ServiceB2...ServiceB100，而且相互之间还可能有依赖关系 。
抛开依赖不说，就拿 ServiceB单纯的单例逻辑代码，重复的逻辑可能需要写成百上千份 。
且扩展不易，以前可能 ServiceB 的操作都不需要事务，后面要上事务了，因此需要改 ServiceB 的代码，嵌入事务相关逻辑 。
没过多久 ServiceC 也要事务，一模一样关于事务的代码又得在 ServiceC 上重复一遍，还有D、E、F...
对几个 Service 事务要求又不一样，还有嵌套事务的问题，总之有点麻烦 。
忙了一段时间满足事务需求，上线了，想着终于脱离了重复代码的噩梦可以好好休息一波 。
紧接着又来了个需求，因为经常要排查线上问题，所以接口入参要打个日志，方便问题排查，又得大刀阔斧操作一波全部改一遍 。
有需求要改动很正常，但是每次改动需要做一大堆重复性工作，又累又没技术含量还容易漏，这就不够优雅了 。
所以有人就开始想办法，想从这个耦合泥沼中脱离出来 。
拔高和剥离人类绝大部分的发明都是因为懒，人们讨厌重复的工作，而计算机最喜欢也最适合做重复的工作 。
既然之前的开发会有很多重复的工作，那为什么不制造一个“东西”出来帮我们做这类重复的事情呢？
就像以前人们手工一步一步组装制造产品，每天一样的步骤可能要重复上万次，到后面人们研究出全自动机器来帮我们制造产品，解放了人们的双手还提高了生产效率 。


推荐阅读


上一篇：Java到底能不能使用异常来控制流程？

下一篇：SIMD助力Photoshop迁移Web？浏览器为何沉迷SIMD？