上期回顾与本期预告：
昨天，我们从一个页面出发，搞清楚了前端，后端，接口的概念。并且还引出了servlet与tomcat。
今天，继续我们的探索之旅，看看又会接触到什么新玩意。

step15：使用servlet输出页面

我在第三天，step8步骤中，告诉了你接口的概念，并且告诉了你前后端的分工。其实，告诉你的有点早了。step8所采用的开发模式就是现在大部分公司采用的前后端分离的模式。但是当时间拨回到多年以前，我们的开发模式可是与今天的前后端分离的模式大不相同的。

多年以前，网页没那么复杂，网页所能做到的功能可能就是展示个企业官网啥的。要么是静态页面，要么是简单的动态页面。如果此时就采用前后端分离的开发模式，很明显无论是在成本上，还是在效率上都不是一个好的选择。毕竟，你想啊，采用分离开发的模式需要前端后端两个人，而且还要协调接口。

所以，多年以前，页面的逻辑和展示全部都是后端一个人做了。那个年代是前端同学最卑微的时候，第一前端人少，一个前端对应n多个后端。其次做的事情简单，他们只能蜷缩在角落里面，切几个图给后端大佬用。切图仔，前端没有技术含量，就是从那个年代传开的。

问题来了，用servlet可以返会json数据，但是servlet还能返会页面吗？当然是可以的！！

现在修改一下 step13中的代码：

启动后，访问：http://localhost:8080/helloworld 结果如下：

神奇吧，servlet可以组装html的内容，然后返回给浏览器。在多年以前，后端程序员就是这么干的，把html，以及引用的js与css都拼接到servlet中。

step16：jsp，曾经的后端页面技术标配

servlet技术看起来已经完全满足我们需要了，能提供接口，也能输出页面。并且在国内百度搜索引擎的策略下（百度目前貌似只支持服务端渲染技术的网页抓取，前后端分离网页的抓取效果不好），servlet简直完美。

但是不幸的是，servlet还是被抛弃了。如果你仔细观察step15的代码，你可能会注意到直接将html代码写在servlet中的缺点。那就是太鸡儿乱了，页面复杂了以后，html代码夹杂着各种标签与转移符号会显得代码又臭又长。你想啊，别说复杂的，就写一个简单的列表展示，你就需要现在servlet中使用jdbc查出数据，再把数据拼接到又臭又长的html代码中，一不小心，还有可能拼接错，导致页面展示不正确。

所以更好的做法是分离，页面和逻辑相分离。这也就是jsp技术的由来。

现在，在webapp目录下，创建一个名为haha.jsp的文件

浏览器访问：http://localhost:8080/haha.jsp

jsp中可以编写java代码，像连接数据库读取数据之类的逻辑都可以写到jsp中。所以你看到jsp的优点是什么了嘛：他分离了servlet页面展示与业务逻辑，使得代码更有利于维护。

但是注意，这里的分离并不是指前后端分离哦，jsp本身就是一个后端技术。在这个阶段jsp页面仍然是由后端人员开发完成的。再说一句，jsp的本质其实还是servlet。

step17：初访springmvc

我们接着来找找茬，servlet以及在其基础上演化的jsp还有没有什么缺点？从演示的过程来看，有些善于总结的小伙伴一定能发现这么些问题：

servlet的演示中，我们提供一个接口，需要在web.xml中配置请求路径及对应的servlet映射。当接口比较多的时候，首先，大部分情况下一个servlet只能提供一个接口（当然有办法提供多个，比如把多个请求路径都映射到一个servlet中，但是不太优雅），这样就导致servlet类会非常多。其次，每个接口都要在web.xml中配置一遍映射关系，有点麻烦。

那jsp呢，当网页应用的界面越来越复杂，后端同学写起jsp中的页面部分时候，越来越力不从心，急需专业的前端同学介入进来。但是前端同学又不懂jsp技术。

好了，我们疯狂的diss了servlet和jsp技术，是时候来场革命了。你通过这一步的标题也能看出来，我准备向你介绍springmvc了。但是准确的来说，springmvc并没有革jsp的命，因为革jsp命的是日益复杂的前端页面和越来越高的前后端分离的呼声。springmvc革的是servlet的命，他通过引入DispatchServlet的机制，加上各种方便的注解，使得我们提供一个接口变得十分的简单方便。

值得注意的是，也许我说革servlet的命有点不妥，因为springmvc内部核心之一还是servlet。因此你可以理解为优化或是升级。

曾经有些小伙伴说，既然springmvc或是springboot是标配了，那干嘛还要学servlet呢？相信看到这一步你们应该明白了吧。

但是，虽然这一步引入了springmvc，但是为时尚早。springmvc依赖于spring技术，我们得先把spring技术了解一下才行。

step18：重头戏来了，spring框架初探

spring框架在java技术栈中的地位不言而喻，哪怕你是个小白，光从各种公司的招聘要求中就能略知一二。可以说，他是目前企业级java开发的标配，非常多的公司直接使用spring框架或是使用基于spring框架为自己公司业务定制的框架。

but，why？理由很简单，一句话解释：spring简化了java开发，降低了大型企业级应用开发的难度。

你随便去翻看一本spring的书籍，一定会发现这么两个关键字。一是IOC（控制反转），另一个是AOP（面向切面编程）。

什么叫她妈的控制反转？控制为什么要反转？反转了有什么好处？

什么叫他妈的面向切面？面向切面了又有什么好处？

我们先从控制反转来回答，这里的控制是对对象创建过程的控制，这里的反转是指从开发者手中转到spring框架手中。说人话就是，以前你自己要通过new构造对象，并且要通过不停的set设置对象之间的依赖关系，现在省事了，直接交给spring去做就好了。

听不懂？举个例子好了，现在有两个类User类和Address类，分别是用户以及用户的住址。

public 

如果我让你创建一个用户，他的名字是张三，年龄是18，省份是浙江，县是杭州。你应该会这么做：

1. 先new一个Address对象
2. 给Address对象的县和省份赋值
3. 再new一个User对象
4. 再给user对象的各个属性赋值

这个过程中，都是你手工一个个做的。如果是spring的话，这些步骤就可以省略了，但是spring也不是神仙啊，他怎么知道我想要一个User对象，他怎么知道我要给user对象里面的字段赋什么值？他又是怎么知道User对象和Address对象的关系？

答案就是：配置。开发人员会编写spring的配置，spring根据配置帮你自动生成你要的对象。

你可能会想，那我也要自己配置啊，跟我一点点手工建立起来相比又有什么好处呢？好处很明显，那就是灵活，足够的灵活。当我们把控制权交给spring以后，spring就成了一个容器。spring在启动过程中，会把我们实现定义在配置文件中的对象都构造好放在一个篮子里面。你用到的时候，只需要从篮子里面取就ok了。还有就是这种机制，非常好的符合设计原则中的开闭原则，如果你需要吧省份改成江苏。那么只需要修改配置文件就行了，代码一句都不用动。这些优点，等你实际用了一段时间之后相信体会更深。咱们怎么说的来着，先用上，再慢慢体会。

现在跟我一起来操作一下，引入spring框架感受一番。

1》按照step6中的步骤，重新创建一个maven项目，命名为step18

2》在step18的pom.xml文件中，假如spring的依赖（要用它，当然要把它加进来了）

<dependency>

3》创建User和Address类

4》创建src/main/resources 文件夹，在其中创建applicationContext.xml文件，里面编写spring的配置。

<?xml version="1.0" encoding="UTF-8"?>

5》编写spring代码，体验ioc

最终的代码结构为：

观察上面的结果，相信你对ioc已经有些体会了。我们只通过配置文件告诉spring我们想要什么对象，真正的创建过程由spring去做了。

ioc你体会了，aop又是什么呢？

step19：再谈spring框架-aop篇

高中时候，我进入了县里面最好的中学，虽然学习环境氛围非常好，但是管的实在是太严格了。对于学生的形象问题要求的尤为苛刻，什么不准打耳钉，女生头发不能过肩，男生头发不能过耳。那个时候，在学校大门口贴了一张大大的告示，上面写着各种形象规范，并且严厉的表示，如果不满足要求，就得回去修整之后才来。

贴告示的方法是比较省力气的，否则就要一个个的通知学生：如果你的形象不符合规则，那么你就得回家。但是贴告示了以后：每个学生看到告示以后便自动的阅读告示，然后执行响应的相应的规则。

如果你还是不够了解，那么我请你想这么一个问题，如果让你编写代码记录每个方法执行的时间，你会怎么做？如果每个方法开始之前先记录起始时间，每个方法执行完成后记录结束时间并计算耗时，那么很明显，你会写非常非常多的重复代码，此时面向切面的编程方式就可以很好的解决你的问题了。

所以，切面就可以理解为学校门口的那个告示，切面里面定义了一些通用的逻辑，并定义了自己的切入规则。

换句话说，切面表达的意思是：如果程序中的方法符合我定义的切入规则，就切入这个方法，执行切面逻辑以后接着再执行原来的方法。这样一来，程序的重复代码会大大减少，对不对。

step20：再访springmvc

上面两个step我们搞定了spring的两大重要特性：IOC和AOP，并且我们也体验了一下一个spring项目的编写和运行流程。现在我们填上step17中的坑，看看springmvc是怎么简化servlet开发的。

废话不多说，跟我一起体验一下springmvc吧：

1》在step18的基础上，参考step12的步骤，将项目改成web项目

2》在pom文件中，添加springmvc的依赖

<dependency>

3》新建名为controller的包，并在其中创建HelloController 的类

package 

4》新建springmvc的配置文件，指定扫描包路径

<?xml version="1.0" encoding="UTF-8"?>

5》在web.xml项目中添加配置，使得web容器与springmvc产生关联

<?xml version="1.0" encoding="UTF-8"?>

6》启动并验证 http://localhost:8080/hello 接口，现象如下

看到这里，可能会有很多迷惑：web.xml中建立容器与springmvc之间的关系是什么意思？看起来springmvc也是需要在web.xml添加配置，跟servlet相比好像也并不简洁啊？

我这里解答一下：建立关系的意思是说，以后容器（tomcat）收到的任何请求都交给配置的springmvc的DispatcherServlet来处理，这个servlet根据我们的RequestMapping注解中指定的路径，将请求/hello又交给我们编写的hello方法来处理，所以最后就返回Hello World了。

虽然目前从web.xml中来看springmvc并不简洁，但是你想啊，springmvc只需要配置这一次，但是servlet要配置很多次（几乎每个servlet就要再配置一次），并且你可以试试在HelloController中再写一个方法叫hello2，然后访问/hello2接口，你就会发现不用任何配置你就多了一个接口，并且这两个接口都是一个Controller提供的。

一个Controller提供N多个接口，是不是解决了之前说的servlet类会膨胀变多的问题了？

到这里还没完，因为这里稍加修改，你也许就更能体会spring的优势了。如果想让你在接口中输出构造好的User对象，你只需要通过@Autowired注解将其从容器中引入进来就可以了。

结果是：

（这里的中文乱码显示的是问号，我就懒得解决了，做些配置就行了）

从上面可以看出来，我们输出了之前放在spring容器中的内容，而且用法非常简单。不知道此时的你，对于控制权交给spring以后（控制反转），从spring容器中，随用随取的便利性是否有了新的体会呢？

最后一点，拖个堂。如果上面的例子中，把@ResponseBody去掉，并将返回值改成hello.jsp

就会发现，再次访问/hello就变成了之前我们写的hello.jsp页面。

所以，有没有再次领悟到springmvc的强大之处，加上注解就是一个数据接口，去掉注解就是一个视图控制器。在这一步，前几年经常用一些模板引擎作为视图层，比如说freemarker ，velocity等。其实说白了，jsp本身也是一个模板引擎。他们之间的区别就不展开了，有兴趣可以百度。

终于完了，今天的内容确实有点多，各位好好消化一下。

如果你喜欢本篇文章，不妨关注一下我的公众号，我会在公众号上发送更多类似风格的文章。相信一定会对你有所帮助。

http://weixin.qq.com/r/8y4eBp7EZMMbrdpl93vh (二维码自动识别)