SpringMVC 九大组件之 ViewResolver 深入分析，2024年最新docker容器面试题

巫俊晤

于 2024-04-09 22:41:24 发布

阅读量428

点赞数 4

分类专栏： 2024年程序员学习文章标签： docker java 容器

本文链接：https://blog.csdn.net/wfegre/article/details/137570862

版权

2024年程序员学习专栏收录该内容

170 篇文章 0 订阅

订阅专栏

可以看到，createView 中调用了 loadView，而 loadView 则是一个抽象方法，具体的实现要去子类中查看了。

这就是缓存 View 的查找过程。

直接继承 AbstractCachingViewResolver 的视图解析器有四种：ResourceBundleViewResolver、XmlViewResolver、UrlBasedViewResolver 以及 ThymeleafViewResolver，其中前两种从 Spring5.3 开始就已经被废弃掉了，因此这里松哥就不做过多介绍，我们主要来看下后两者。

4.1 UrlBasedViewResolver

UrlBasedViewResolver 重写了父类的 getCacheKey、createView、loadView 三个方法：

getCacheKey

@Override

protected Object getCacheKey(String viewName, Locale locale) {

return viewName;

}

父类的 getCacheKey 是 viewName + '_' + locale，现在变成了 viewName。

createView

@Override

protected View createView(String viewName, Locale locale) throws Exception {

if (!canHandle(viewName, locale)) {

return null;

}

if (viewName.startsWith(REDIRECT_URL_PREFIX)) {

String redirectUrl = viewName.substring(REDIRECT_URL_PREFIX.length());

RedirectView view = new RedirectView(redirectUrl,

isRedirectContextRelative(), isRedirectHttp10Compatible());

String[] hosts = getRedirectHosts();

if (hosts != null) {

view.setHosts(hosts);

}

return applyLifecycleMethods(REDIRECT_URL_PREFIX, view);

}

if (viewName.startsWith(FORWARD_URL_PREFIX)) {

String forwardUrl = viewName.substring(FORWARD_URL_PREFIX.length());

InternalResourceView view = new InternalResourceView(forwardUrl);

return applyLifecycleMethods(FORWARD_URL_PREFIX, view);

}

return super.createView(viewName, locale);

}

首先调用 canHandle 方法判断是否支持这里的逻辑视图。
接下来判断逻辑视图名前缀是不是 redirect:，如果是，则表示这是一个重定向视图，则构造 RedirectView 进行处理。
接下来判断逻辑视图名前缀是不是 forward:，如果是，则表示这是一个服务端跳转，则构造 InternalResourceView 进行处理。
如果前面都不是，则调用父类的 createView 方法去构建视图，这最终会调用到子类的 loadView 方法。

loadView

@Override

protected View loadView(String viewName, Locale locale) throws Exception {

AbstractUrlBasedView view = buildView(viewName);

View result = applyLifecycleMethods(viewName, view);

return (view.checkResource(locale) ? result : null);

}

这里边就干了三件事：

调用 buildView 方法构建 View。
调用 applyLifecycleMethods 方法完成 View 的初始化。
检车 View 是否存在并返回。

第三步比较简单，没啥好说的，主要就是检查视图文件是否存在，像我们常用的 Jsp 视图解析器以及 Freemarker 视图解析器都会去检查，但是 Thymeleaf 不会去检查（具体参见：SpringMVC 中如何同时存在多个视图解析器一文）。这里主要是前两步，松哥要和大家着重说一下，这里又涉及到两个方法 buildView 和 applyLifecycleMethods。

4.1.1 buildView

这个方法就是用来构建视图的：

protected AbstractUrlBasedView buildView(String viewName) throws Exception {

AbstractUrlBasedView view = instantiateView();

view.setUrl(getPrefix() + viewName + getSuffix());

view.setAttributesMap(getAttributesMap());

String contentType = getContentType();

if (contentType != null) {

view.setContentType(contentType);

}

String requestContextAttribute = getRequestContextAttribute();

if (requestContextAttribute != null) {

view.setRequestContextAttribute(requestContextAttribute);

}

Boolean exposePathVariables = getExposePathVariables();

if (exposePathVariables != null) {

view.setExposePathVariables(exposePathVariables);

}

Boolean exposeContextBeansAsAttributes = getExposeContextBeansAsAttributes();

if (exposeContextBeansAsAttributes != null) {

view.setExposeContextBeansAsAttributes(exposeContextBeansAsAttributes);

}

String[] exposedContextBeanNames = getExposedContextBeanNames();

if (exposedContextBeanNames != null) {

view.setExposedContextBeanNames(exposedContextBeanNames);

}

return view;

}

首先调用 instantiateView 方法，根据我们在配置视图解析器时提供的 viewClass，构建一个 View 对象返回。
给 view 配置 url，就是前缀+viewName+后缀，其中前缀后缀都是我们在配置视图解析器的时候提供的。
同理，如果用户在配置视图解析器时提供了 content-type，也将其设置给 View 对象。
配置 requestContext 的属性名称。
配置 exposePathVariables，也就是通过 @PathVaribale 注解标记的参数信息。
配置 exposeContextBeansAsAttributes，表示是否可以在 View 中使用容器中的 Bean，该参数我们可以在配置视图解析器时提供。
配置 exposedContextBeanNames，表示可以在 View 中使用容器中的哪些 Bean，该参数我们可以在配置视图解析器时提供。

就这样，视图就构建好了，是不是非常 easy！

4.1.2 applyLifecycleMethods

protected View applyLifecycleMethods(String viewName, AbstractUrlBasedView view) {

ApplicationContext context = getApplicationContext();

if (context != null) {

Object initialized = context.getAutowireCapableBeanFactory().initializeBean(view, viewName);

if (initialized instanceof View) {

return (View) initialized;

}

return view;

}

这个就是 Bean 的初始化，没啥好说的。

UrlBasedViewResolver 的子类还是比较多的，其中有两个比较有代表性的，分别是我们使用 JSP 时所用的 InternalResourceViewResolver 以及当我们使用 Freemarker 时所用的 FreeMarkerViewResolver，由于这两个我们比较常见，因此松哥在这里再和大家介绍一下这两个组件。

4.2 InternalResourceViewResolver

当我们使用 JSP 时，可能会用到这个视图解析器。

InternalResourceViewResolver 主要干了 4 件事：

通过 requiredViewClass 方法规定了视图。

@Override

protected Class<?> requiredViewClass() {

return InternalResourceView.class;

}

在构造方法中调用 requiredViewClass 方法去确定视图，如果项目中引入了 JSTL，则会将视图调整为 JstlView。
重写了 instantiateView 方法，会根据实际情况初始化不同的 View：

@Override

protected AbstractUrlBasedView instantiateView() {

return (getViewClass() == InternalResourceView.class ? new InternalResourceView() :

(getViewClass() == JstlView.class ? new JstlView() : super.instantiateView()));

}

会根据实际情况初始化 InternalResourceView 或者 JstlView，或者调用父类的方法完成 View 的初始化。

buildView 方法也重写了，如下：

@Override

protected AbstractUrlBasedView buildView(String viewName) throws Exception {

InternalResourceView view = (InternalResourceView) super.buildView(viewName);

if (this.alwaysInclude != null) {

view.setAlwaysInclude(this.alwaysInclude);

}

view.setPreventDispatchLoop(true);

return view;

}

这里首先调用父类方法构建出 InternalResourceView，然后配置 alwaysInclude，表示是否允许在使用 forward 的情况下也允许使用 include，最后面的 setPreventDispatchLoop 方法则是防止循环调用。

4.3 FreeMarkerViewResolver

FreeMarkerViewResolver 和 UrlBasedViewResolver 之间还隔了一个 AbstractTemplateViewResolver，AbstractTemplateViewResolver 比较简单，里边只是多出来了五个属性而已，这五个属性松哥在之前和大家分享 Freemarker 用法的时候都已经说过了（参见：Spring Boot + Freemarker 中的弯弯绕！），这里再和大家啰嗦下：

exposeRequestAttributes：是否将 RequestAttributes 暴露给 View 使用。
allowRequestOverride：当 RequestAttributes 和 Model 中的数据同名时，是否允许 RequestAttributes 中的参数覆盖 Model 中的同名参数。
exposeSessionAttributes：是否将 SessionAttributes 暴露给 View 使用。
allowSessionOverride：当 SessionAttributes 和 Model 中的数据同名时，是否允许 SessionAttributes 中的参数覆盖 Model 中的同名参数。
exposeSpringMacroHelpers：是否将 RequestContext 暴露出来供 Spring Macro 使用。

这就是 AbstractTemplateViewResolver 特性，比较简单，再来看 FreeMarkerViewResolver。

public class FreeMarkerViewResolver extends AbstractTemplateViewResolver {

public FreeMarkerViewResolver() {

setViewClass(requiredViewClass());

}

public FreeMarkerViewResolver(String prefix, String suffix) {

this();

setPrefix(prefix);

setSuffix(suffix);

}

@Override

protected Class<?> requiredViewClass() {

return FreeMarkerView.class;

}

@Override

protected AbstractUrlBasedView instantiateView() {

return (getViewClass() == FreeMarkerView.class ? new FreeMarkerView() : super.instantiateView());

}

FreeMarkerViewResolver 的源码就很简单了，配置一下前后缀、重写 requiredViewClass 方法提供 FreeMarkerView，重写 instantiateView 方法完成 View 的初始化。

ThymeleafViewResolver 继承自 AbstractCachingViewResolver，具体的工作流程和前面的差不多，因此这里也就不做过多介绍了。需要注意的是，ThymeleafViewResolver#loadView 方法并不会去检查视图模版是否存在，所以有可能会最终会返回一个不存在的视图（参见：SpringMVC 中如何同时存在多个视图解析器一文）。

5.ViewResolverComposite

最后我们再来看下 ViewResolverComposite，ViewResolverComposite 其实我们在前面的源码分析中已经多次见到过这种模式了，通过 ViewResolverComposite 来代理其他的 ViewResolver，不同的是，这里的 ViewResolverComposite 还为其他 ViewResolver 做了一些初始化操作。为对应的 ViewResolver 分别配置了 applicationContext 以及 servletContext。这里的代码比较简单，我就不贴出来了，最后在 ViewResolverComposite#resolveViewName 方法中，遍历其他视图解析器进行处理：

@Override

@Nullable

public View resolveViewName(String viewName, Locale locale) throws Exception {

for (ViewResolver viewResolver : this.viewResolvers) {

View view = viewResolver.resolveViewName(viewName, locale);

if (view != null) {

return view;

}

return null;

}

6.小结

好啦，今天主要和小伙伴们聊了下 SpringMVC 中视图解析器的工作流程，结合松哥之前的文章SpringMVC 中如何同时存在多个视图解析器，相信大家对于 SpringMVC 中的视图解析器的理解会更进一步。
好啦，今天就先和大家聊这么多～