写出MVC的工作原理

Posted 2023-03-17

1.当用户在浏览器中点击一个链接或者提交一个表单时，那么就会产生一个请求（request）。当请求离开浏览器时，它会携带用户请求的信息。

2.请求的第一站到达的是Spring的DispatcherServlet，它是一个前端控制器，工作是将用户的请求委托给其他的组件（这里是交给Spring MVC的控制器）去处理。

这里DispatcherServlet要决定将请求传给哪一个控制器（Controller）去处理，那么这时就需要处理器映射（Handler Mapping）了。

处理器映射会看请求的URL信息，然后决定将请求交给哪一个控制器去处理。比如说有两个控制器ControllerA和ControllerB，分别处理后缀名为.html和.jsp送来的请求，那么当请求者的后缀名为.html时，那么DispatcherServlet就将请求交给ControllerA进行处理。

C代表Controller，负责用户界面和业务逻辑层的通信控制，一方面解释来自用户界面的输入，识别用户动作（如点击按钮等），调用相应Model中的方法，另一方面处理来自Model的事件和返回的执行结果，调用适当的View显示给用户，Controller主要由Servlet完成。

M代表Model，负责整个解决方案的业务逻辑实现，底层的数据库也由Model访问和操作；

V代表View，负责系统向用户的展示，主要由HTML及JSP等完成；

拓展资料：

MVC组件说明：

以下组件通常使用框架提供实现：

DispatcherServlet：作为前端控制器，整个流程控制的中心，控制其它组件执行，统一调度，降低组件之间的耦合性，提高每个组件的扩展性。

HandlerMapping：通过扩展处理器映射器实现不同的映射方式，例如：配置文件方式，实现接口方式，注解方式等。 

HandlAdapter：通过扩展处理器适配器，支持更多类型的处理器。

ViewResolver：通过扩展视图解析器，支持更多类型的视图解析，例如：jsp、freemarker、pdf、excel等。

组件：
1、前端控制器DispatcherServlet（不需要工程师开发）,由框架提供
作用：接收请求，响应结果，相当于转发器，中央处理器。有了dispatcherServlet减少了其它组件之间的耦合度。

用户请求到达前端控制器，它就相当于mvc模式中的c，dispatcherServlet是整个流程控制的中心，由它调用其它组件处理用户的请求，dispatcherServlet的存在降低了组件之间的耦合性。

2、处理器映射器HandlerMapping(不需要工程师开发),由框架提供
作用：根据请求的url查找Handler

HandlerMapping负责根据用户请求找到Handler即处理器，springmvc提供了不同的映射器实现不同的映射方式，例如：配置文件方式，实现接口方式，注解方式等。

3、处理器适配器HandlerAdapter
作用：按照特定规则（HandlerAdapter要求的规则）去执行Handler

通过HandlerAdapter对处理器进行执行，这是适配器模式的应用，通过扩展适配器可以对更多类型的处理器进行执行。

4、处理器Handler(需要工程师开发)

注意：编写Handler时按照HandlerAdapter的要求去做，这样适配器才可以去正确执行Handler
Handler 是继DispatcherServlet前端控制器的后端控制器，在DispatcherServlet的控制下Handler对具体的用户请求进行处理。

由于Handler涉及到具体的用户业务请求，所以一般情况需要工程师根据业务需求开发Handler。

5、视图解析器View resolver(不需要工程师开发),由框架提供
作用：进行视图解析，根据逻辑视图名解析成真正的视图（view）

View Resolver负责将处理结果生成View视图，View Resolver首先根据逻辑视图名解析成物理视图名即具体的页面地址，再生成View视图对象，最后对View进行渲染将处理结果通过页面展示给用户。

springmvc框架提供了很多的View视图类型，包括：jstlView、freemarkerView、pdfView等。

一般情况下需要通过页面标签或页面模版技术将模型数据通过页面展示给用户，需要由工程师根据业务需求开发具体的页面。

6、视图View(需要工程师开发jsp...)
View是一个接口，实现类支持不同的View类型（jsp、freemarker、pdf...）

参考资料：百度百科-MVC

参考技术A 　　MVC的工作原理：
　　①当用户在浏览器中点击一个链接或者提交一个表单时，那么就会产生一个请求（request）。当请求离开浏览器时，它会携带用户请求的信息。
　　②请求的第一站到达的是Spring的DispatcherServlet，它是一个前端控制器，工作是将用户的请求委托给其他的组件（这里是交给Spring MVC的控制器）去处理。这里DispatcherServlet要决定将请求传给哪一个控制器（Controller）去处理，那么这时就需要处理器映射（Handler Mapping）了。处理器映射会看请求的URL信息，然后决定将请求交给哪一个控制器去处理。比如说有两个控制器ControllerA和ControllerB，分别处理后缀名为.html和.jsp送来的请求，那么当请求者的后缀名为.html时，那么DispatcherServlet就将请求交给ControllerA进行处理。
　　③当选择了一个合适的控制器后，DispatcherServlet就会将请求交给这个控制器去处理。在这个控制器上，用户的请求将会将用户提交的一些信息交由控制器处理并等待。然而设计的比较好的控制器本身对信息做很少的处理或者根本不做处理，而是将业务逻辑交给一个或多个服务器对象（Model）去处理。
　　④当控制器对用户请求所携带的信息进行处理（或交给模型层处理）后，经常会产生一些其他的需要返回给浏览器进行显示的数据。这些原始数据直接显示出来显然是不友好的，那么就需要视图（View）来对这些数据进行显示了。控制器的最后一件事就是将模型数据打包，并且指定产生输出的视图的特定名称，然后它将模型、视图名称以及request请求一起发送给DispatcherServlet。所以控制器并没有与视图进行耦合，因为传递给DispatcherServlet的视图名称并不是某一个指定的特殊的文件名称（如后缀名一定是JSP或其他什么名称），它只要是一个可以产生输出和展示结果的逻辑名称就可以了。
　　⑤DispatcherServlet会向一个视图解析器（ViewResolver）进行请求，视图解析器可以将逻辑视图名称映射到一个特定的视图显示文件上面。
　　⑥现在DispatcherServlet知道哪一个视图文件可以显示结果了。该视图将会利用模板数据产生输出，这些输出通过response对象返回给客户端进行显示。 参考技术B 模型－视图－控制器（MVC）是Xerox PARC在八十年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 php 的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。

MVC如何工作

MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。

视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services.
如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。

模型
模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。
现在我们总结MVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。

为什么要使用 MVC
大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。
首先，最重要的一点是多个视图能共享一个模型，正如我所提及的，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。
由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。
因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从mysql移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。
对我来说，控制器的也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。

MVC的缺点
MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。
你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。

根据我个人经验，由于我们将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。
MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
MVC是一条创建软件的好途径
MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。

Java开发Web Application有几种符合MVC设计模式的开发方式。
1:Jsp+Servlet+JavaBean(EJB)
2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model)
3:TDK(Turbine，Velocity...)
4:Xsp
5:Jsp+Struts+JavaBean(EJB)

附：
三层架构即“表现层”，“业务层”，“持久化层”。表现层实现的代表作品是Struts框架，业务层实现的代表作品是Spring，持久层实现的代表作品是Hibernate。
举个例子。
持久层从持久库中取出-10。
业务层按照一定的逻辑（这里我们举例取温度的逻辑）翻译成-10摄氏度。
表示层显现给用户“哎呀，今天好冷！”。
层就相当于一个黑盒子，我们不用知道它内部怎么实现，只需要知道如何去调用它就行了。每层只与上下相邻的两层打交道。当一层内部由于技术变迁发生变化时，只要接口不变，其他层不用做任何改变。分层之后灵活性提高，也便于团队分工开发。本回答被提问者和网友采纳

Spring MVC工作原理及源码解析 MVC原理介绍与IOC容器整合原理

MVC原理介绍

Spring MVC原理图

 

上图是Spring MVC工作原理图（图片来自网上搜索），根据上图，我们可以得知Spring MVC的工作流程如下：

1、用户（客户端，即浏览器）发送请求至前端控制器（DispatcherServlet） 。

2、前端控制器收到请求后调⽤处理器映射器（HandlerMapping）。

3、处理器映射器根据请求Url找到具体的处理器（Handler，也叫后端控制器），生成处理器对象及处理器拦截器（如果有）一并返回给前端控制器。

4、前端控制器收到处理器对象及处理器拦截器（如果有）后调用处理器适配器（HandlerAdapter）去调用Handler。

5、处理器适配器执行处理器。

6、处理器执行完后给处理器适配器返回ModelAndView。

7、处理器适配器将ModelAndView（ModelAndView是SpringMVC框架的⼀个底层对象，包括 Model 和 View）返回给前端控制器。

8、前端控制器接收到ModelAndView后，请求视图解析器（ViewResolver）去进⾏视图解析，根据逻辑视图名来解析真正的视图。

9、视图解析器将解析完的View返回给前端控制器。

10、前端控制器进⾏视图渲染，就是将模型数据（在 ModelAndView 对象中）填充到 request 域。

11、前端控制器向⽤户响应结果。

与IOC容器整合原理

下图是Spring MVC的IOC容器与Spring的IOC容器整合的示意图，采用SSM框架的整合方式：

 

当用户发送请求到服务器时，Spring MVC的前端控制器DispatcherServlet会启动一个IOC容器，而Spring的核心监听器ContextLoaderListener也会启动一个IOC容器。

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="WebApp_ID" version="2.5">
    
    <servlet>
        <servlet-name>springDispatcherServlet</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <!-- 自定义Spring MVC配置文件的位置和名称 -->
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>classpath:spring-mvc.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>springDispatcherServlet</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>
    
    <!-- 在Servlet的上下文参数中指定Spring配置文件的配置 -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:spring-tx.xml</param-value>
    </context-param>
    
    <listener>
        <!-- 配置ContextLoaderListener监听器，初始化WebApplicationContext这个类型的IOC容器 -->
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    
</web-app>

多IOC容器整合导致的对象重复创建问题

当两个IOC容器分别扫描不同的包时不会有重复创建对象问题

比方说，

Spring MVC的IOC容器扫描：com.ioc.component.handler，

Spring的IOC容器扫描：com.ioc.component.service，com.ioc.component.dao。

此时不会出现重复创建对象的问题。

当两个IOC容器扫描同一个包时会有重复创建对象问题

比方说，在特定情况下 两个IOC容器都扫描同一个包：com.ioc.component，此时如果不做特殊处理，会存在对象重复创建问题。

 

在实际开发中，一般需要将两者分开，避免出现扫描同一个包的问题。

1、同时配置两个IOC容器

为了实现更好的解耦，我们在实际开发中往往还是需要将数据源、Service、Dao等组件配置到传统的Spring配置文件中，并通过ContextLoaderListener启动这个IOC容器，而负责处理请求的handler组件则是由SpringMVC自己来启动，这就会产生一个问题：同样的组件可能会被创建两次。

2、两个IOC容器各自的配置

为避免对象被重复创建，两个IOC容器需要分别进行如下配置。

对于Spring的IOC容器，将标记了@Controller注解的bean排除，不进行该类对象的创建工作。

Spring配置文件：spring-tx.xml

<context:component-scan base-package="com.ioc.component.*">
    <!-- 过滤规则：exclude-filter 排除指定的类 -->
    <!-- 将@Controller注解标记的类从自动扫描的包中排除 -->
    <!-- 效果：当前IOC容器不会创建@Controller注解标记的类的bean -->
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

对于Spring MVC的IOC容器，仅创建标记了@Controller注解的bean。

SpringMVC配置文件:spring-mvc.xml

<!-- 关键：仅 -->
<!-- 配置use-default-filters="false"将默认的扫描包规则取消，参考include-filter仅创建@Controller注解标记的类的bean -->
<context:component-scan base-package="com.ioc.component.*" use-default-filters="false">
    <!-- 过滤规则：include-filter 创建指定的类 -->
    <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

这两个IOC容器中，先启动的那个将成为后启动的IOC容器的父容器。

小结

Spring MVC的前端控制器DispatcherServlet读取spring-mvc.xml配置文件，Spring的核心监听器ContextLoaderListener读取spring-tx.xml配置文件。

要想避免两个IOC容器重复创建对象的问题，就需要分别在两个配置文件中进行配置，指定两个容器分别需要创建哪些对象。

 

IOC容器部分 参考文章链接：https://blog.csdn.net/java_wxid/article/details/84798991