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了。