Pulp dental system Model-View-Controller Frame

The Spring framework has its own MVC Web application framework, which was not originally intended. The developers of Spring decided to write their own web framework as a reaction to what they perceived as the bad design of the (then) popular Jakarta Struts Web framework, Other frames available. In particular, they found that there was insufficient separation between the presentation and request processing layers and between the application processing layer and the model

Like Struts, Spring MVC is a query-based framework. The framework defines the policy interfaces for all responsibilities that must be addressed by a modern demand-driven framework. The goal of each interface is to be simple and clear so that it is easy for Spring MVC users to write their own implementations if they wish. MVC paves the way for a cleaner front end code. All interfaces are tightly coupled to the Servlet API. This tight coupling to the Servlet API is perceived by some as a failure on the part of Spring's developers to provide high-level abstraction for Web applications [citation needed]. However, this coupling ensures that the functionality of the Servlet API remains available to developers while providing a high abstraction framework to facilitate work with said API.

The DispatcherServlet class is the front-end controller  of the framework and is responsible for delegating control to the different interfaces during the execution phases of an HTTP request.

The most important interfaces defined by Spring MVC and their responsibilities are listed below:

Controller: Between Model and View to handle incoming requests and redirect to the correct answer. It acts as a gateway that directs incoming information. It switches between the entry in the model or the view.

HandlerAdapter: Running objects that handle incoming requests

HandlerInterceptor: Incoming query interception comparable but not equal to Servlet filters (use is optional and not controlled by DispatcherServlet).

HandlerMapping: selection of objects that handle incoming requests (managers) according to any attribute or condition internal or external to these requests

LocaleResolver: resolution and optionally saving the locale of an individual user

MultipartResolver: makes it easy to work with file downloads by wrapping incoming requests

View: Responsible for returning a response to the client. Some requests can go directly to the view without going to the template part; Others can go through all three.

ViewResolver: Select a view based on a logical name for the view (use is not strictly required)

Each strategy interface above has an important responsibility within the overall framework. The abstractions offered by these interfaces are powerful, to allow a set of variations in their implementations, Spring MVC embeds with implementations of all these interfaces and together offers a set of features on top of the Servlet API. However, developers and vendors are free to write other implementations. Spring MVC uses the Java interface java.util.Map as a data-oriented abstraction for the model where the keys are supposed to be string values.

The ease of testing the implementations of these interfaces seems to be an important advantage of the high level of abstraction offered by Spring MVC. DispatcherServlet is tightly coupled to the control container's spring inversion to configure application web layers. However, Web applications can use other parts of the Spring Framework, including the container, and choose not to use Spring MVC.