Spring核心技术原理-（1）-经过Web开发演进过程了解一下为何要有Spring?

1、知史能够明鉴

咱们学习技术的时代遇上了最好的时代，跳过了不少前人常常踩的坑，前人在踩坑的过程当中总结了不少经验和教训，而新时代的咱们只是继承了前人的经验和教训，而忽略了这些采坑的过程，以致于咱们面对不少新技术都不知道他是什么？他为何存在？他为何能够解决这个问题？更不知道如何掌握其原理！云里雾里一头雾水！

交流群的不少小伙伴，经常私聊我让我推荐一下学习SSM框架的视频和资料，我首先会打开他的资料卡看一下他的年龄，若是超过了他这个年龄应有的水平，我就会问他JSP+Servlet学了吗？不少小伙伴的回答是简单的学了一下，而后，我会给他一个关于JSP+Servlet的实战项目，顺便给他们找一些SSM的项目，而且建议他们首先看这个JSP+Servlet的实战项目。

更有甚者，学了基础以后就开始学习Spring Boot的，当问他们Spring Boot是什么的时候，大体也能够回答出来“约定大于配置”，“用起来很简单”，可是在细究其原理，也是吱吱呜呜，只知其一;不知其二！若是咱们没有经历过Spring最开始繁琐的配置、而后一步步精简，根本体会不到为何会有Spring Boot这个东西！

不先学习常见的设计模式直接看Spring、MyBatis等源码，简直就是一个找虐的过程！不掌握Servlet原理、基本的Tomcat容器技术上来就看Spring MVC源码一样也是一个打击自信心的好地方！

学习是一个按部就班的过程，不能急于求成，但也不能过度钻牛角尖！不能再一个技术上停滞不前，也不能如"走马观花"通常寥寥掠过！一样，若是你尚未掌握好Servlet和简单的设计模式我建议你先去查阅相关的资料进行系统的学习。

我也相信不少图书或视频等资料都忽略了讲述为何会有Spring的过程，要么是简单归纳而且痛斥EJB的各类弊端，要么就是只字不提，这是一种对读者很不负责任的表现，知史能够明鉴！所以，在进一步学习Spring核心原理以前，咱们有必要介绍一下整个Web发展的简单历史，一步步引出为何会有Spring！

2、Web发展简史

老一辈的软件开发人员通常经历了从Model1到Model2，而后到后来的三层模型，最后到如今的Spring Boot。若是从Model1到Model2提及到咱们如今使用的Spring Boot为整个时间轴的话，大体能够分为4个阶段：

（1）初级阶段：使用Model1/Model2/三层模模型进行开发；

（2）中级阶段：使用EJB进行分布式应用开发，忍受重量级框架带来的种种麻烦；

（3）高级阶段：使用Spring春天带给咱们的美好，可是还要忍受不少繁琐的配置；

（4）骨灰级阶段：使用Spring Boot，畅享“预约大于配置”带给咱们的种种乐趣！

3、Web发展初级阶段

一、Model1开发模式：

Model1的开发模式是：JSP+JavaBean的模式，它的核心是Jsp页面，在这个页面中，Jsp页面负责整合页面和JavaBean（业务逻辑），并且渲染页面，它的基本流程以下：

相信不少小伙伴在刚学习Web的时候，确定使用到了Model1开发模式，也就是咱们的业务代码、持久化代码直接写在Jsp页面里边，使用Jsp直接处理Web浏览器的请求，并使用JavaBean处理业务逻辑。

利用咱们如今熟悉的MVC模型的思想去看，虽然编写代码十分容易，但Jsp混淆了MVC模型中的视图层和控制层，高度耦合的结果是Jsp代码十分复杂，后期维护困难！

二、Model2开发模式：

Model1虽然在必定程度上解耦了，但JSP依旧即要负责页面控制，又要负责逻辑处理，职责不单一！此时Model2应运而生，使得各个部分各司其职，Model2是基于MVC模式的。

Model2的开发模式是：Jsp+Servlet+JavaBean的模式，它和Model1不一样的是，增长了Servlet，将调用页面数据，调用业务逻辑等工做放到了Servlet中处理，从而减轻了Jsp的工做负担！它的基本流程以下：

Model2开发模式将Servlet的概念引入架构体系中，使用它来分配视图层Jsp的显示页面，同时调用模型层的JavaBean来控制业务逻辑。

三、Model1和Model2的区别：

Model1：简单，适合小型项目的开发，可是Jsp的职责过于繁重，职责分工不明确。在后期的维护工做中，必将为此付出代价！

Model2：相对于Model1来讲，职责分工更为明确，在Model1的基础上，抽取了Servlet层，体现了一个分层的思想，适合大型的项目开发！（当时的评判标准是适合大型项目开发的，如今看起来已通过时了！）

Model2看起来已经尽善尽美了，尽管如此，他还不能称之为一个比较完善的MVC设计模式！

四、Model1和Model2与三层的对比：

在Model2中，咱们将Servlet抽取出单独的一层，和Jsp协做完成用户数据交互的工做，也就是表示层。那么做为三层结构来讲，又作了什么样的改进呢？三层则是在此基础上，将JavaBean再一次进行分割：业务逻辑、数据持久化，三层以下：

（1）表示层，JSP/Servlet； （2）业务逻辑层：业务规则； （3）持久化层：主要包装持久化的逻辑 ；

各个的耦合性以下图：

Model一、Model二、三层是在解耦的基础上一步步进化而来，经过解耦咱们能够进行进一步的抽象，以应对现实需求的变更。

4、Web发展中级阶段、高级阶段和骨灰级阶段

这一小节彷佛有点应付，对于中级阶段，由于我没有用过EJB，在这里不敢妄加评论，以避免误导你们。可是相信每一位接触过Spring的小伙伴，都应该知道Rod Johnson在2002年编写的《Expert One-to-One J2EE Design and Development》一书，Rod 在本书中对J2EE正统框架臃肿、低效、脱离现实的种种学院派作法提出了质疑，并以此书为指导思想，编写了interface21框架，也就是后来的Spring。

对于高级阶段和骨灰级阶段是咱们后期一系列文章的重点，本篇只做为一个阶段划分，不作过多的解释，所以让咱们从新回到Web发展的初级阶段。

对EJB有兴趣的能够参考文章：www.uml.org.cn/j2ee/200911…

5、Web发展初级阶段存在的问题

经历过初级阶段的小伙伴确定看得懂下边的一个项目结构，一个简单的MVC三层结构，使用JSP+Servlet+MySQL+JDBC技术，面向接口编程：

一、面向接口编程的实例化对象

以用户管理模块为例，有一个UserDao接口，有一个接口的实现类UserDaoImpl，以下：

因为是面向接口编程，所以咱们在每次使用UserDao的时候，都要进行实例化一次，实例化代码以下：

UserDao userDao = new UserDaoImpl();
复制代码

咱们在每次使用UserDao的时候都须要进行实例化，固然不只仅有UserDao须要进行实例化，还有不少须要进行实例化的，举例以下：

能够看出，每个方法中都须要进行实例化咱们须要用到的接口的实现类，这就会存在大量的实例化对象，而且他们的生命周期可能就是从方法的调用开始到方法的调用结束为止，加大了GC回收的压力！

二、使用单例模式的一次改进

了解设计模式的可能会想到使用单例模式的方式来解决这个问题，以此来避免大量重复的建立对象，可是咱们还要考虑到众多的这种对象的建立都须要改为单例模式的话，是一个耗时耗力的操做。

对于这个系统来讲，若是都把这种面向接口的对象实现类转换为单例模式的方式的话，大概也要写十几个或者上百个这种单例模式代码，而对于一个单例模式的写法来讲，每每是模板式的代码，以静态内部类的方式实现单例模式以下：

能够看出，这种方式有两个问题：

（1）业务代码与单例模式的模板代码放在一个类里，耦合性较高； （2）大量重复的单例模式的模板代码；

从上述能够看出，使用的单例模式虽然从性能上有所提升，可是却加剧了咱们的开发成本。所以只会小规模的使用，例如咱们操做JDBC的Utils对象等。

三、咱们开发中遇到的痛点

从上述代码的演进过程咱们能够看得出来，咱们即须要一个单例的对象来避免系统中大量重复对象的建立和销毁，又不想由于使用单例模式形成大量重复无用的模板代码和代码的耦合！

（忽然想到一个段子，想和你们分享一下：产品经理在给甲方汇报方案的时候说了两种方案：一种是实用的，一种是美观的，问甲方但愿选择哪种？甲方说：有没有即实用又美观的！）

四、咱们还能怎么作

做为学院派的书生来讲，咱们可能会联想到“数据库链接池”,咱们在获取数据库链接的时候会从这个池子中拿到一个链接的，假设这个数据库链接池很特殊，有且只能有N个数据库链接，而且每个链接对象都不一样（假设），那么这个不就至关于每个链接都是单例的了吗？既能够避免大量对象的建立，也能够实现不会出现大量重复性的模板代码。

所以，这里应该有一个大胆的想法，咱们是否能够创建一个池子，将咱们的接口实现类对象放入到这个池子中，咱们在使用的时候直接从这个池子里边取就好了！

五、这个池子

若是咱们要建立这个池子，首先要肯定须要把哪些对象放进这个池子，经过怎样的方式放进去，放进去以后如何进行管理，如何进行获取，池子中的每个对象的生命周期是怎么样的等等这些东西都是咱们须要考虑到的！

六、恭喜你

若是你已经了解了上述Web演进的过程，以及咱们想要建立的这个池子，那么恭喜你！你已经打开了Spring核心原理的大门了！

上述咱们想要建立的池子其实就是Spring容器的雏形，将接口实现类的对象放进池子进行管理的过程其实也是Spring IOC依赖注入、控制反转的雏形！

Spring的依赖注入/控制反转就是从咱们的配置文件或注解中的获得咱们须要进行注入到Spring容器的实现类的信息，Spring IOC经过这些配置信息建立一个个单例的对象并放入Spring容器中，Spring容器能够看作是一个集合保存着咱们的这些对象。

七、小总结

上文中主要从一个切入点探讨了一下为何有Spring，以及介绍了一下Spring IOC和Spring容器的基本雏形概念，固然还能够从其余方面进行切入。这里没有进一步探讨AOP的概念，对于新入门的小伙伴来讲，这个确实有必要讨论一下，也决定在后续文章中由浅入深的探讨一下，而对于老手来讲，其实我上边写的基本上是浪费你们时间的！

6、总结

从历史的角度来讲，不一样时期的大革命在爆发以前，都会有一个蓄谋已久的“导火线”！Spring的出现，一样顺应了历史发展潮流，正是因为那个时期J2EE开发标准的种种弊端造就了Spring的出现！即便不是Spring，一样也会有其余相似的产品出现，只不过历史选择了Spring，Spring顺应了历史！没有切肤之痛，是不会体会到Spring带给咱们的乐趣与快感！

一样的，每一个时代都会有每个时代的问题，Spring也是！正如十年前咱们的计算机可能带不动一款游戏，今天咱们的计算机也有可能带不动一款现在的游戏，一样十年后的计算机也会有一款他带不动的游戏出现！以一种发展的眼光去看Spring，就能够很好的理解Spring Boot是以一种什么样的角色出如今咱们的面前了！

时代选择了Spring，一样Spring也被这个时代所选择着！你我只有不停的进步，不停地学习才能跟上这个时代！

【视频福利】2T免费学习视频，搜索或扫描上述二维码关注微信公众号：Java后端技术（ID: JavaITWork）回复：1024，便可免费获取！内含SSM、Spring全家桶、微服务、MySQL、MyCat、集群、分布式、中间件、Linux、网络、多线程，Jenkins、Nexus、Docker、ELK等等免费学习视频，持续更新！