手写Spring框架---MVC实现

目录

预备

自研框架MVC的实现

MVC架构草图：

大致流程

实现思路

自定义注解

JavaBean

请求的拦截-建立DispatcherServlet

责任链处理请求

RequestProcessor矩阵

Render矩阵

---

• 预备

• 在DispatcherServlet：
  • 解析请求路径和请求方法
  • 依赖容器，建立并维护Controller方法与请求的映射
  • 用合适的Controller方法去处理特定的请求
• 参照SpringMVC，仅通过DispatcherServlet进行请求派发这样可以让系统模块更加明确，该类的任务有：
  • 拦截全部请求
  • 解析请求
  • 派发给对应的Controller里面进行处理
• 通过下面的注解可以拦截到全部请求

  

• 由于给DispatcherServlet标记了@WebServlet("/")，所以在tomcat启动之后会将DispatcherServlet给加载进来

  

• 因为设置了/匹配所有的的url-pattern，而且在tomcat插件中的设置了项目的根路径，/${project.artifactId}可以获取项目的名字，这样设置之后以项目名为根路径的请求都会经由DispatcherServlet来处理，里面的service方法就是用来处理请求的

  

• 相关的请求就会交给DispatcherServlet来处理，在DispatcherServlet加载到tomcat里面之后，在首次接收外部请求的时候，会调用里面init方法来完成自身的初始化，初始化之后调用service来处理相关的请求
• 后续的请求再到来时不会再执行初始化方法，直接调用service方法来处理请求
• HttpServletRequest里面包含了请求路径和请求方法以及请求里面的业务参数
• 通过类似简单工厂方法的模式解析请求方法和请求路径，按照请求路径和请求方法转发到对应的controller方法处理
• 在实际的使用中可以选择将返回的数据转换为json格式返回给前端，或者也可以生成相关的页面视图返回给前端去做渲染
• 下面的会对jsp请求也会进行拦截，如果我们在页面中转发到jsp，就依然会被拦截到这个类里

  

• 原因在tomcat的web.xml中，反斜杠是Servlet中特殊的匹配模式，优先级最低，比*.jsp优先级低，但是反斜杠星号属于路径匹配，优先级比*.jsp高

  

• 自研框架MVC的实现

• MVC架构草图：

  

• 大致流程

• 获取http请求和需要回发的http响应对象，之后将他们委托给RequestProcessorChain处理
• 我们只处理get和post方法的请求，RequestProcessorChain参照的是责任链模式的后置处理器的处理逻辑，里面保存了处理RequestProcessor接口的多个不同的实现类，之所以会有多个不同的实现类对应为DispatcherServlet是项目里面所有请求的唯一入口
• DispatcherServlet[ 调度Servlet ]的作用是将请求分发到不同的处理器
• 这些请求里即会有获取jsp页面的请求，也会有获取静态资源的请求、直接获取json数据的请求等，针对不同的请求会使用不同的RequestProcessor来处理
• Spring MVC框架像许多其他MVC框架一样，以请求为驱动，围绕一个中心Servlet分派请求及提供其他功能，DispatcherServlet是一个实际的Servlet (它继承自HttpServlet 基类)

  

• 简要分析执行流程
  • 1-DispatcherServlet表示前置控制器，是整个SpringMVC的控制中心
  • 用户发出请求，DispatcherServlet接收请求并拦截请求
  • 假设请求的url为：http://localhost:8080/SpringMVC/hello
  • 如上url拆分成三部分：
    • http://localhost:8080服务器域名
    • SpringMVC部署在服务器上的web站点
    • hello表示控制器
  • 通过分析，如上url表示为：请求位于服务器localhost:8080上的SpringMVC站点的hello控制器
  • 2-HandlerMapping为处理器映射；DispatcherServlet调用HandlerMapping，HandlerMapping根据请求url查找Handler
  • 3-HandlerExecution表示具体的Handler，其主要作用是根据url查找控制器，如上url被查找控制器为：hello
  • 4-HandlerExecution将解析后的信息传递给DispatcherServlet，如解析控制器映射等
  • 5-HandlerAdapter表示处理器适配器，其按照特定的规则去执行Handler
  • 6-Handler让具体的Controller执行
  • 7-Controller将具体的执行信息返回给HandlerAdapter，如ModelAndView
  • 8-HandlerAdapter将视图逻辑名或模型传递给DispatcherServlet
  • 9-DispatcherServlet调用视图解析器(ViewResolver)来解析HandlerAdapter传递的逻辑视图名
  • 10-视图解析器将解析的逻辑视图名传给DispatcherServlet
  • 11-DispatcherServlet根据视图解析器解析的视图结果，调用具体的视图
  • 12-最终视图呈现给用户

• 实现思路

  • 自研框架实现思路定义DispatcherServlet分发器
  • 创建责任链对象实例
  • 通过责任链模式来依次调用请求处理对请求进行处理
  • 对处理结果进行渲染

• 自定义注解

  • @RequestMapping 标识controller的方法和请求路径和请求方法的映射问题

    

  • @RequestParam 请求方法参数名

    

  • @ResponseBody 用于标记自动对返回值进行json处理

    

• JavaBean

  • ControllerMethod 待执行的Controller及其方法实例和参数的映射

    

  • ModelAndView 存储处理完后的结果数据以及显示该数据的视图

    

  • RequestMethod 框架目前支持的请求方法

    

  • RequestPathInfo 储存http请求路径和请求方法

    

• 请求的拦截-建立DispatcherServlet

  • 初始化容器
  • 初始化请求处理器责任链
  • 通过责任链模式来依次调用请求处理器对请求进行处理
  • 对处理结果进行渲染

    

  • init方法
    • 对常驻变量进行初始化
    • servlet是程序执行的入口：对容器进行初始化并将相关的bean加载进来，同时完成AOP相关逻辑的织入，以及相关的IoC依赖注入等操作
    • 因为后面是采用责任链模式来实现RequestProcessor矩阵的，要将对应的处理器添加到处理器列表中
    • 将RequestProcessor矩阵按序添加到缓存列表里
    • 之所以按照图示的顺序进行添加，是因为我们的请求经过编码和路径的处理之后才能进行后续的处理
    • 将ControllerRequestProcessor放在最后是因为它的处理会比较耗时，需要将请求和controller的方法实例进行匹配
  • service方法
    • 首先创建责任链对象实例
    • 然后通过责任链模式来依次调用请求处理器对请求进行处理
      • 通过迭代器遍历注册的请求处理器实现类列表
      • 直到某个请求处理器执行后返回false为止
      • 期间如果出现异常，则交由内部异常渲染器处理
    • 最后对处理结果进行渲染
      • 如果请求处理器实现类均未选择合适的渲染器，则使用默认的
      • 调用渲染器的render方法对结果进行渲染

• 责任链处理请求

• 以责任链的模式执行注册的请求处理器
• 委派给特定的Render实例对处理后的结果进行渲染

  

• RequestProcessor矩阵

  

  • PreRequestProcessor处理器(请求预处理器)：主要负责对请求的编码以及对路径做一些前置处理

    

  • 剩余的处理器都会去解析请求，以看看请求是否由该处理器去处理的
  • StaticResourceRequestProcessor处理器(静态资源处理器)：对静态资源请求

    

  • 利用的tomcat默认请求派发器RequestDispatcher处理
  • JspRequestProcessor处理器(JSP处理器)：对jsp页面的访问请求进行处理（不仅过controller直接访问页面的请求）

    

  • 利用的tomcat的jspServlet处理
  • ControllerRequestProcessor处理器(Controller处理器)：将请求派发到对应的controller方法里面进行处理
    • 针对特定请求，选择匹配的Controller方法进行处理
    • 解析出请求里的参数及其对应的值，并赋值给Controller方法的参数
    • 选择合适的Render，为后续请求处理结果的渲染做准备

      

    • 建立Controller方法与请求的映射关系
      • 请求中包含的信息有路径和请求参数，所以需要根据这些信息找到对应的Controller方法
      • 利用RequestPathInfo存储请求的信息，ControllerMethod存储Controller以及方法的信息
      • 建立的映射关系就是RequestPathInfo与ControllerMethod的，这样就可以根据请求定位到对应的方法
    • 然后利用ConverterUtil给需要执行的方法参数赋值
    • 最后利用反射执行获取执行的结果，根据结果设置结果渲染器

• Render矩阵

  • 渲染，处理了相关的请求之后，需要将结果以不同的形式给展现出来，并且处理的过程中可能会出现各种各样的异常，也需要去做体现
  • Render负责对结果进行包装并展现
  • 当处理器处理完之后就会调用特定的实现了Render接口的实现类，对处理结果进行展现

    

  • DefaultResultRender(默认结果渲染器)：当请求处理成功后，用户只需要返回一个成功的状态码
    • 如果请求处理器实现类均未选择合适的渲染器，则使用默认的结果渲染器
    • 主要将处理的结果状态码返回，默认为200

      

  • JsonResultRender(Json结果渲染器)：用户发送的请求是想要获取json格式的返回结果
    • 当方法上面使用@ResponseBody 注解时，利用Gson将结果转换成Json数据返回

      

  • ViewResultRender(视图解析器)：将逻辑视图转换成用户可以看到的物理视图，类似于ModelAndView对象
    • 视图解析器则根据返回结果的不同，而进行跳转
    • 如果是String数据，则创建一个ModelAndView对象，并将数据加入到视图地址
    • 如果是ModelAndView，则会解析其中的视图地址和数据
    • 针对其他情况，则直接抛出异常

      

  • InternalErrorResultRender(异常结果渲染器)：对异常的处理
    • 以责任链的模式处理请求，期间如果出现异常，则交由内部异常渲染器处理
    • 设置状态码500和异常信息

      

  • ResourceNotFoundResultRende(找不到路径渲染器)：资源无法找到的异常
    • 在根据请求路径转发到Controller时，找不到对应的对象或者方法，则使用该渲染器
    • 返回404和请求的路径及方法

      

• 测试成功