程序员|Java程序员应知应会,为什么现在我们不用Servlet了?

程序员|Java程序员应知应会,为什么现在我们不用Servlet了?

文章图片


每个学习Java的同学都会从Servlet开始学习 。 Servlet API发表于1998年 , 可以说 JavaEE众多API中最成功的一个 。 多年以来 , 它的核心API一直变化不大 , 非常的稳定 。
但是 , 新入行的程序员们现在却很少用它了 , 甚至很多人如果是转行过来 , 直接就开始写项目的话 , 可能完全不熟悉Servlet的编码风格了 。 程序员们可能已经习惯了基于Spring MVC的Spring boot风格 , 已经熟悉了Restful的开发方法 。 那么 , 我们真的不再使用Servlet了吗?答案是否定的 , 我们依然在使用Servlet , 只不过原来是我们直接写Servlet , 而现在是框架代替我们完成Servlet的工作而已 。
类似于Structs、Spring MVC等框架 , 它们的核心理念都是Servlet与handler之间的一个mapping 。
以Spring MVC为例 , 它有一个DispatherServlet , 负责处理请求 , 并且调用了我们写的Controller 。 作为Controller的前端控制器DispatcherServlet最终是继承了HttpServlet的 , 只不过springmvc帮助你做好了url和method的映射了(注解实现) , 不需要你自己在web.xml一个servlet和一个method去配置了 。
DisPatcherServlet是Spring中唯一的Servlet , Servlet将所有请求都转发到DisPatcherServlet , 然后DisPatcherServlet分发请求通过HandlerMapping(处理器映射器)和HandlerAdapter(处理器适配器)找到具体的Controller 。 而Controller只是一个普通的JavaBean 。
DisPatcherServlet的生命周期和Servlet是相同的 , 都是在第一次被访问时创建 , 容器关闭时销毁 。 具体的过程如下图所示:

那么为什么我们需要框架去做这些工作呢?这就不得不提到Servlet本身存在的一些缺点和不便之处了 。
Servlet最大的缺点是一个类只能写一个接口 , 而每一个Servlet都要在web.xml中进行相应的配置 , 我们想在一个Servlet里写很多个方法的话 , 则需要采用传递参数的形式 , 分解到每一个方法中 。 如果有很多Servlet , 就会导致web.xml内容过于繁多 。 而这样的结构很明显是不利于分组开发的 。
另外 , 在Servlet中 , doGet方法和doPost方法有HttpServletRequest和HttpServletResponse参数 。 这两个参数与容器相关 , 如果想在servlet中作单元测试 , 则必须初始化这两个参数 。 在我们目前已经习惯了进行单元测试的情况下 , Servlet就显得很不方便 。
因此 , 人们才用框架把Servlet封装起来 , 替我们完成这些繁琐的工作 , 从而增加开发效率 。
所以 , 事实上并不是我们不用Servlet了 , 而是基于Servlet实现的各类框架 , 替我们完成了相关的工作 , 从而不需要我们自己编写Servlet了 。
【程序员|Java程序员应知应会,为什么现在我们不用Servlet了?】