ViewResolver用来根据逻辑视图名称，解析到真正的视图，视图可以由jsp构成，freemarker构成。
今天稍微看了看freemarker的视图解析器，不知为何，工作电脑上的eclipse的tomcat自动部署有问题，改写ftl文件，总是不能快速的部署到应用里面去。
1.AbstractCachingViewResolver
这个类直接实现ViewResolver接口，实现了一些基本的视图缓存工作。
首先，这个类实现了在ViewResolver接口中定义的resolveViewName方法，这个方法首先判断是否使用缓存，如果使用，则还是由这个类的处理，因为本身就缓存起来了以前的视图，所以，可以在这个类内部的缓存中取出视图，而如果不使用缓存，则直接调用createView方法，这个方法嘛，又调用了抽象的loadView方法，就是留给子类实现的抽象方法。
那么，这个类是怎么缓存视图的呢？
有2个内部变量来实现缓存，一个是viewAccessCache，这个变量是个Map，key存储视图名称，value存储具体的View接口的实现类对象。
另一个变量是viewCreationCache，也是一个Map。2个Map的用途都是存储view，但第一个Map速度快，优先访问，第二个Map复写了removeEldestEntry方法，用于实现仅仅保存
cacheLimit个view。
2.UrlBasedViewResolver
这个类其实是利用文件路径来模仿url的规则，所以叫UrlBased,其他也可以叫其他的好听的名字，比如UrlLiked，这个就比较贴切了。
这个类其实就是实现loadView方法的一个类，其实就是根据viewName来装备具体的View的路径了，有一些额外的通用路径可以配置，比如前缀，后缀，基础目录，还有一些其他配置。
还带有检查是否有具体资源的功能，但这个功能是这街使用view自己提供的方法，毕竟，只有view自己知道真实的视图在哪里，是否存在。不过，直接返回true了，挺敷衍的。
ps:这里需要前缀，后缀，还有基础目录的原因是什么呢？
其实，使用配置化的前缀，后缀，就是因为mvc模式里面的v可以具有多种实现方式，而model却可以是一样的，这样，利用前缀，后缀，同一个model可以由不同的view来展现，可以用jsp来实现，可以用ftl来实现，自由灵活，可以同时存在。
3.InternalResourceViewResolver
这个类就是jsp视图的解析器了，非常常用，没有什么奇特的，就是调用父类的一些方法而已。
4.AbstractTemplateViewResolver
抽象的模板视图解析器
5.FreeMarkerViewResolver
这个类就是ftl文件的视图解析器了，本身还是利用freemarker的template的能力，也不多说了，代码挺简单的。
这里有个值得借鉴的思路，对于mvc模式，里面的v可以由不同的实现，那么这个v就是个接口，那么，针对每种不同接口的实现，就响应有一个能够根据视图名称解析到真正视图的解析器，那么这里的v的实现类和响应的解析器，就是1对1的关系了，简单明了。
还有个很有意思的方法调用方式，
processTemplate(getTemplate(locale), fmModel, response);
然后processTemplate方法里面的代码是这样的
template.process(model, response.getWriter());
其实，这样的代码是很有讲究的。
针对Resolver梳理清楚了，那么针对view，应该也就清楚了，其实每种view就是包括一个request，一个response，还有一些其他配置信息，渲染，就调用view的render方法，简单明了。