概述

  • 只有把握了JavaSE的常识，以及B/S架构申请和响应的流程，就可能看懂，反射的部份占得比拟多，还有注解

  • 应用环境：

    • JDK：1.8
    • Tomcat：9.0.3
    • 编译器：IDEA 2019

原生Servlet的问题

  • Servlet的作用：

    • Servlet的作用是解决浏览器发送过去的申请以及服务器响应回去的信息
    • 通过浏览器发送过去的资源申请，转发给对应的资源

  • 原生Servlet的写法：

    • 1）在web.xml对一个Servlet进行配置
    • 2）实现Servlet接口/继承HttpServlet
    • 3）重写doPost/doGet/Service办法

  • 原生Servlet产生的问题：

    • 1）配置信息多：每写一个Servlet类须要配置8行xml
    • 2）每个Servlet类都要实现/继承，减少耦合度
    • 3）一个Servlet类只对应了一个性能，当我的项目中的性能越来越多时，Servlet类也会越来越多

解决策略

  • 1）将多个Servlet的办法封装到一个Servlet中

    • 这样一个Servlet类就对应了多个性能

  • 2）封装一个DispatcherServlet类，这个类依据浏览器的资源申请，找到对应的Servlet，以及解决Servlet类的响应

    • 也就是这个DispatcherServlet类是惟一一个继承HttpServlet/实现Servlet接口，而之前写的Servlet类就是一般的类
    • 这样做升高了耦合度，web.xml配置文件中也只须要配置DispatcherServlet，缩小了配置信息

封装后的组件

  • 如上图所示，次要封装了两个组件，别离是DispatcherServlet和Handler

  • DispatcherServlet的作用：

    • 1）接管浏览器发送过去的申请
    • 2）将申请交给Handler

  • Handler的作用：

    • 1）解析申请
    • 2）找到解决该申请的对象
    • 3）找到该对象具体解决该申请的办法
    • 4）解析执行对象执行办法后的后果
    • 5）将后果响应回给浏览器

  • ModelAndView：

    • 这个对象是用来存储服务器返回的转发/重定向门路，以及服务器要返回的参数

  • ApplicationContext.properties：

    • 这个配置文件是用来存储申请名字对应的解决对象的类门路

应用办法

@SessionAttributes("name")public class AtmController {//须要治理这个Controller的单例机制 private AtmService service = new AtmService(); public ModelAndView login(User user){        ModelAndView mv = new ModelAndView(); String result = service.login(user); if("success".equals(result)){ mv.addObject("name",user.getName());//如果存在session中 先放在mv容器里 mv.setViewName("welcome.jsp"); }else{            mv.addObject("result",result); mv.setViewName("index.jsp"); }        return mv; }     @ResponseBody public List<User> query(){        List<User> userList = service.query(); return userList; }}
  • 比方如上代码：

  • 几个自定义注解的含意：

    • @SessionAttributes("参数名")：

      • 这个注解的作用是把参数存到session作用域里
      • 必须写在类名下面
      • 存入的参数必须是在request作用域外面存在的

    • @ResponseBody：

      • 写在办法下面
      • 如果返回的是实体对象、List对象、JSON对象、String字符串，则须要加上这个注解

    • @RequestParam("参数名")：

      • 写在办法携带的参数后面，注解里写的名字和办法的参数名统一
      • 如果浏览器发送的申请携带了参数，那么执行的对象不须要通过request对象就能拿到参数
    • 如果参数是一个实体对象/Map对象，那么就不须要写@RequestParam注解，框架会主动把申请携带的参数包装成一个对象

局限性

  • 因为工夫不够短缺，所以只是简略的封装，所以应用的时候也是有很多问题，比方对于办法参数解决以及响应信息的解决类型只能解决几个根本数据类型、实体对象以及Map、list汇合和Json对象
  • 封装这个的意义次要是练习JavaSE的常识，以及理解真正的管制层的框架是怎么解决的，所以如果真的感兴趣的能够照着我这个思路持续写下去

代码地址：https://github.com/Cing-self/...