A ViewResolver in Spring MVC translates the logical view name a controller returns into an actual view object that can render a response, keeping controllers unaware of the concrete rendering technology.
Key Points: • Controllers return a plain String or a ModelAndView carrying just a view name, like "home", not a file path. • InternalResourceViewResolver applies a configured prefix and suffix, so "home" becomes /WEB-INF/views/home.jsp. • The resolved View object is then handed the model data and asked to render the response. • This indirection decouples controller logic from the view technology, so you can swap JSP for Thymeleaf without touching controllers. • Multiple resolvers can be registered with priority ordering when an app mixes view technologies.
Example: A controller method returning "userProfile" combined with a prefix of /WEB-INF/views/ and a suffix of .jsp resolves to /WEB-INF/views/userProfile.jsp, which Spring then forwards the request to for rendering.
Code Example:
@Bean
public ViewResolver viewResolver() {
InternalResourceViewResolver resolver = new InternalResourceViewResolver();
resolver.setPrefix("/WEB-INF/views/");
resolver.setSuffix(".jsp");
return resolver;
}Interview Tip: A concise interview answer is:
"A ViewResolver takes the logical view name a controller returns and maps it to an actual view file, usually by combining a configured prefix and suffix. This keeps controllers decoupled from the rendering technology — the controller just says 'home', and the resolver figures out that means /WEB-INF/views/home.jsp."