122-SpringMVC入门案例之总结和扩展

好，那我们spring mvc入门案例里面，咱们功能已经测试完了，对吧？该如何处理请求，该如何去设置我们当前咱们的控制器方法，控制器方法的返回值又是干什么的，大家一定要知道啊行，那下面呢，那我们再继续往下看，然后咱们在这儿呢，给大家来总结一下，就是说我们当前spring VC它到底是如何来处理请求的呢？大家注意，其实这就是一个简单的一个运行原理，对吧？运行过程咱们看一下啊，浏览器就是我们能从我们的这个运行过，就是我们能从咱们所实现的功能里面能看出来的一个过程啊。大家想一下是什么过程？浏览器发送一个请求，若请求地址符合前端控制器，也就是dispatch of的URL patternthon，也就是我们在外部点叉ML中设置的这个东西，对吧？那咱们写的是斜线对吧？它除了点GSP匹配匹配不到，其他的是不是都能够匹配得到对不对？好，然后再往下，然后该请求就会被咱们的前端控制器dispa solve进行处理，哎，前端控制器呢，会读取spring VC的核起和这个核心配置文件，通过扫描组件，然后来找到咱们的控制器，也就是我们的控制层组件，大家注意，就是这个controller，知道吧？然后下面呢，那不就是要拿着我们当前的请求跟咱们的控制层里面的request mapping进行比较了吗？是不是如果我们当前发送的请求的请求地址跟我们request mapping里面的这个value属性值一致，那我们当前这个注解所标识的方法就是处理请求的方法？

对不对，对吧，然后呢，我们当前就执行这个方法，然后处理请求，然后最终咱们所返回的字符串就是我们要跳转到的页面的逻辑视图，然后这个时候逻辑视图会被我们的核心配置文件中的这个什么呀，视图解析器来进行解析，然后加上我们当前咱们所设置的视图前缀，加上咱们当前设置的视图后缀，那不就是一个完整的物理视图嘛，对不对，然后最后呢，由咱们的c lef，因为咱们这是c lef的视图解析器，所以说由c Le来进行视图渲染，来跳转页面。

大家注意，就是这样的一个过程啊，咱们继续往下看，然后通过扫描组件找到控制层，将咱们请求地址和控制器中的request mapping注解的value属性值。来进行匹配。若匹配成功。然后则注解所标识的控制器方法，就是处理请求的方法对不对？然后处理请求的方法需要返回一个字符串类型的视图名称，大家注意，这个叫视图名称啊，也叫做什么？其实就是咱们c lef中的逻辑视图，知道吧？然后呢，该视图名称会被视图解析器解析，加上前缀加上后缀，组成一个完整视图的路径，然后通过SIM Le对视图进行渲染，最终转发到咱们视图所对应的页面。大家注意，这肯定是转发，不可能是重定向啊，你想想咱们首先web银付下面的页面。

Web info下面的页面，你通过重电项你能访问的了，不访问不了对吧？再说了，咱们的C你都用了c lef了，C Le是我们服务器中试图渲染的技术，所以说你当前的页面必须得在服务器中来进行渲染，所以说我们当前只能通过转发来访问到我们这个页面，你绝对不能用重定项来访问啊。好，再说大家看一下，你看咱们的这个这个浏览器里面的地址，你看如果要是重定项，这地址不就变了吗？对吧？地址是不是就会变成是咱们success.HTML的路径，但是地址变了没有没有还是哈喽，所以说在这用的一定是转发啊，这个大家看好了。至于重定向该怎么实现，咱们后边会给大家去讲啊，行，那我们现在把咱们的spring VC，然后来处理请求的整个流程呢，咱们看完之后，下面给大家讲一些咱们扩展的一些内容，就比如说咱们的配置文件，对吧？咱们的配置文件咱们一般是不是都要放在咱们的resource之下，那我们现在咱不想把它放在这个位置，我们应该怎么去做对不对？好，大家看啊，来找到咱们的web差名，来找到我们当前的solve标签，然后在我们的solve标签中，我们可以来使用一个初始化参数来设置，叫做in para。

这个大家应该都见过吧，叫init per是设置solve的初始化参数的，咱们来选择哪个，这里面有提示啊，不用自己写，叫context conflictf location叫做上下文配置路径，其实就是来设置我们当前dispat of要加载的spring VC的路径的，Spring VC的配置文件的路径的，知道吧？好，然后大家看看在这咱们怎么做啊，你可不能直接写个名字就完事了，你要把拉pass加上，然后再写咱们当前配置文件的路径，配置文件的名称，比如说咱们就叫做spring mvc，点叉ML，或者说大家叫做spring mvc，小写的也行，知道不？哎，行，然后点叉苗就可以了啊好，然后那我们现在把这个设置完，你看它报错，为啥报错？因为我们现在没有吗？对不对？你看咱们的类路径下，类路径指的是谁？Java是不是算是类路径？Resource是不是也算是类路径？那下面有这个配置文件吗？

没有，所以说呢，大家注意，我们现在只需要在我们当前的resource下面来创建一个spring mvc点叉ML，点击OK，大家再看web点叉ML，你看还报错不报了。我报错了吧，所以说前面这class你一定得写上，如果说你不写，它指的还是外部银付，知道不指的还是外部银付啊，所以说咱们的class pass指的是类路径，那类路径的话，咱们放在Java下也行，Resource下也行，当然resource是我们专门来存放配置文件的路径，所以说咱们直接放在这下面就可以啊，好，然后后边这个是我们当前配置文件的名字，对不对啊，你指定它叫什么，咱们在这就给它创建一个相对应的文件就可以啊，好，下面咱们把这个给它干掉。

大家注意，在这咱们就不需要重新去建了啊，然后点击OK，只要有一个就行，好，然后呢，我们现在咱们再来一个重新部署，大家注意你往下拉的太多的话，这不看不到吗？你点击这个位置看到没有，然后它就可以把咱们隐藏的一些按钮给我们展示出来，OK吧，行，下面我们在这咱们再回来，然后刷新。啊，然后刷新。啊，这是什么情况，Spring mvc点叉ML没有找到是吧？那没有找到的话，但是我们在这咱们是不是有啊，有但是它没有找到，大家说是不是有可能是因为什么？有可能是因为我们当前。然后我们这个配置文件创建的，但是它没有加载到在我们当前咱们的这个袜包里面，它没有在这个指定位置，没有，对不对，所以咱们把咱们的target给打开，然后打开之后大家再来看，咱们把咱们的这个挖包啊也给它打开，然后咱们来找到谁找到web in for，因为我们的这个Java下面的内容和resource下面的内容，它最终是不是都会放在咱们的web info下面的classes下面，对不对？大家看一下，你看有没有没有，那没有的话，那我们怎么办？大家找到maven，然后来找到我们当前的这个工程，然后life circle，咱们先给它清理一下啊，然后清理之后我们当前编译咱们的这个构建之后的结果。

啊。这是什么情况？来，咱们先把它给关掉啊。好，应该是我们当前的工程正处在运行状态啊，然后下面咱们来一个clean，大家注意。好，大家看直接build success对不对，然后下面呢，咱们这个把它给清理完成之后，咱们在这再来重新一个打包就行啊，或者说大家直接在这启动就可以，就没问题了，知道吧，然后我们来看一下target，然后找到我们当前的这个袜包，然后再来找到web in class，大家看配置文件是不是就有了，OK吧，行，然后呢，我们现在咱们来一个运行啊，因为刚才给咱们报的错里面不知道大家看到了没有，里面有一个叫做fair not的，他说我们sp.XML啊，然后他报的一个错叫做这个文件是not phone的exception什么意思，文件未找到，那不就说明我们当前咱们的袜包里面是在这个指定的位置没有这个文件，对不对，对吧？好，大家看这时候是不是就没问题了，咱们点击之后，你看没有问题。

能看懂吧，好，所以啊，大家注意，以后大家可能也会遇到相同的问题，就比如说呀，然后我们当前你是对吧，复制过来，特别是咱们复制过来的一个文件对吧？你复制过来之后，很有可能它在袜包里面所对应的位置是没有这个是没有这个文件的，怎么办？大家找到咱们的ma，把我们当前咱们的target的下面内容给它清理掉之后，然后咱们再重新打包，或者说你再重新运行就可以了，能听懂吧，这样的啊好，那这个标签是用来干什么的，大家注意，然后在这，然后咱们是用来设置spring mvc配置文件的位置和名称，OK，这是这个标签的功能，好，那我们再来看啊，那想必大家之前在学习solve的时候啊，大家应该也学习过这样的一个标签，叫什么标签，看好啊，叫做load on up。

叫做load on start up干啥的？将solvele的初始化时间提前到服务器启动时，那我们之前咱们在学习solve的时候，大家学过solve的生命周期，Solve light的生命周期一共有三个步骤，首先是初始化，第二个步骤是服务，第三个步骤是销毁，然后咱们的solvel它的初始化默认是在什么时候执行的？默认是在我们当前服务器启动啊不是，是在咱们第一次访问时执行的，对吧？好。

那大家想一下啊，那我们当前咱们的这个dispatch of，这是咱们的框架给我们创建出来的，对不对，那它的初始化里面是不是应该会做很多很多的一些操作呀，是不是是吧，或者说我们也可以在这简单的看一下，大家注意我把这个东西给点开，然后点开之后呢，那咱们也不知道这里面初始化它又它都要干啥呀，咱们就简单的快速的去看一下，大家注意等到以后咱们再具体的去看啊，好，你看它继承的是framework solve，点开然后framework solve，然后又继承了httb solve b httb solve b又继承了http solve httb继承了generate solve，而generate solve实现了solve接口来这个和这个还有这个这三个大家应该都认识吧。是不是啊，这个是so的接口里面初始化的方法，来咱们把这个给点开啊，叫structure，或者说out加七，来查看当前这个类的内部结构，然后初始化的方法是init，在generate solve里面呢。

初始化的方法是谁呀？因为大家注意这是一路继承过来的，知道不，或者说实现过来的，所以说我们当前的dispature ofle里面啊，它是不是应该会把咱们当前所有它所实现的接口，或说或者说是它继承的类里面所有的方法都继承到dispat of that中，对不对，这样的啊，好，那我们来看。那dispatch ofle里面，我们要想来看它是怎么进行的初始化，那我们只要顺着我们当前的一个继承关系去看咱们初始化的方法，一步一步是怎么被重写的就行，对不对？好，来大家注意啊，这是我们当前重写的inite，这是我们前重载的inite，在这有一个向上的箭头，就是重写的方法，知道吧，重写的solve中的啊，好，然后在这里面呢，这这两个是引it，这两个是初始化啊，然后咱们再继续往下看http solve里面有没有来重写初始化的方法，没有，为什么？因为它在generate solve里面已经重写过了，所以说它没有重写，再看这个，这里面有没有init，大家看好，有啊，而且init初始化的是谁，Gene ofet。

OK吧，为啥？因为他没有出这个金融重写嘛，对不对？所以说我们当前他的初始化方法继承给了他，然后他是不是他再去继承它的时候，然后他是不是就对这个初始化进行了重写，来咱们打开看一下，你看他都干了点啥，咱们往下走对吧，然后再往下走，大家注意最终它调用的是init solve let bin，然后我们再来找到init solve bin，你点开之后，你会发现这里面啥都没有，对不对，那说明什么？啊，那大家想想那说明什么？咱们只要看到这种情况，那不就说明这个方法是让谁去重写的，让它的子类去重写的吗？对不对，对吧，然后我们再来找到framework solve，然后现在咱们就不需要再去看了啊，咱们应来应该来看的是in solve病，然后把它给打开之后，大家看，你看这里面的东西呢，老多了是不是？哎，老多了啊好，那它在这又干了什么？你看叫做初始化web application contest这个东西大家这个你不认识啊，但是我们应该是认识这个的，叫application contest什么东西，IOC容器。

其实这大家应该也认识，我们在讲咱们的IOC容器的一些相对应的API的时候，就讲过这个web application contest，这是在我们的web应用中所使用的IOC容器，对不对？好啊，然后它是不是在这初始化了我们的web application contest，也就是咱们的。IOC容器，然后又调用了一个方法叫in。Framework of that对不对？在哪呢？大家看这方法咱们就不看了，以后咱们再看啊。

然后in framework of that在哪？在这呢？看是不是在这里面呢，但是这里面又什么都没有写，那这说明啥？那这是不是就说明我们当前咱们它是不是也要被它的子类去重写，对不对啊好，然后咱们把它给打开，叫in it solve let，叫做in it solve that。来看一下啊。啊，找一下吧，搜一下吧，太多了啊好，然后咱们在这来一个CTRL加F，然后大家看你看这里面没有，那没有的话，那说明它的子类有没有重写，没有重写对吧？好，然后但是呢，这中间还有一个步骤，大家记不记得啊，就是在我们的这里面阴历的so的B中，咱们在这是不是初始化了一个IOC容器，那咱们把它给打开，你看这里面执行的东西多不多，那是相当的多，对不对，然后里面有一个比较重要的地方叫做on freshsh，叫做刷新容器。然后大家看好，你看它在这调用了一个on freshsh，那onf freshsh里面又执行的什么啥都没写对不对，大家注意，这也是咱们初始化的过程执行的内容啊，然后咱们再来找到那这个方法没有重写，那咱们是不是就要来找到dispat of that里面，看它有没有重写了，对不对，On fresh。

Unfresh。啊。在这呢，大家看啊好，然后在这个unfresh方法里面，然后它又调用了一个in，叫做straties方法，叫做初始化策略，这个大家就先看一下，我只是想跟大家说明一个问题，就是我们当前dispatch solve在初始化的时候做的东做的操作非常非常的多。知道不，我只是想让大家看这个啊，然后呢，我们看这个方法又是干啥的？初始化策略，你看这里面初始化咱们当前的什么multi part reserve，这是咱们的文件上传解析器，然后咱们来找一个认识的叫in review reservever，能看懂吧，所以说大家注意啊，你看我们当前咱们的初始化的操作里面呢，做了老多的操作了，对不对？那所以大家想，如果我们当前咱们在配置我们的dispat of that的时候，我们。

我们就这样去配置的话，或者说咱们现在没有设置这个标签，那我们当前咱们的spring VC它的前端控制器在第一次去访问的时候进行初始化，那咱们在第一次访问的时候是不是就要做很多很多的操作，就要花费很长的时间，想必大家应该也都能够看出来，我们第一次在访问咱们的首页的时候，就是服务器启动之后访问首页的时候，这个圈其实转了有好几秒，对不对对，为什么这样大家注意就是因为什么，因为我们当前通过源码咱们也能看到，在dispatch so初始化的过程中，它执行的操作是非常非常多的，那所以说我们最好啊，不要让咱们的dispatch solve在第一次访问时初始化，这样的时候，咱们第一次访问的时候就要花费很长时间，然后进行初始化，并且来处理这个请求，所以说建议大家在这加上一个load on的up标签，然后将当前serve的初始化时间提前到什么时候服务器启动时。

置能听懂吧，这个时候咱们就不会出现什么了，你第一次访问的时候是不是要花费很长时间呢？因为因为如果你要不设置，那咱们第一次访问的时候，他不但要来处理请求，是不是还要进行一个漫长的初始化的过程，OK吧，行，这个大家注意啊，所以我刚才呢，就是咱们把这些什么so，所有的solve继承的过程中的这些类，对吧，还有抽象类，咱们让大家去看一下，主要是为啥，就是让大家知道初始化的过程中执行的操作很多，咱们最好不要让他在第一次访问时实现初始化，要不然的话，咱们就要花费大量的时间去执行初始化的过程，然后导致我们第一次去访问的时候花费的时间很长，知道吧，行啊，好，那这个标签是干什么的？大家注意将咱们的dispa of let的初始化时间，然后提前到服务器启动时，OK啊？

行，那这就是我们当前的一个扩展配置，对吧？咱们可以自定义spring mvc配置文件的位置和名称，然后我们是不是也可以将咱们的solve，将咱们的前端控制器，它的初始化时间提前到服务器启动时，啊，行，那这就是我们的入门案例，然后呢，大家一定要把这个功能实现，然后呢，再去根据我们所实现的功能，然后结合着我们当前总结的这个内容。然后大家去看一下，然后看我们当前spring mvc它是不是按照这个过程来实现的，OK吧，行啊。