关于java:Java手动封装Servlet

概述

• 只有把握了 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/…