本文旨在整理对JavaWeb开发历史发展的认识。感谢各路大佬的分享心得，引用已放在底部。

不得不说，Servlet+JSP+JDBC的传统开发已经是“久远”的过去了，现在很少有公司直接使用 这一套技术栈 来写项目了，新手也往往跳过了这一阶段的学习，直接拥抱了SSM时代。

那么都2024年了，这套技术栈还需要学习吗？真的有必要吗？

我不能简单地给出是与否的回答。我也是直接从SSM入门的JavaWeb，Spring优秀到让我足以不了解底层运作，也能随心所欲地开发JavaWeb项目。但从学习的一开始我大概知道SpringMVC的底层离不开Servlet，尤其最近出于对Spring源码的学习，我越发觉得了解JavaWeb发展的历史是十分有必要的。

我们可以不必深究过往技术的具体实现，因为站在巨人的肩膀上我们无需重复造轮子；但我们需要了解技术的发展史，站在当下，要回望过去，才能更好地明白今日从何而来，未来将往哪去。

java Web的演变过程大概可以分为4个阶段：

jsp + Servlet + jdbc

spring + struts2+ hibernate(ssh)

spring + SpringMVC + mybatis(ssm)

微服务阶段。

本文将以JavaWeb前后端分离前后为主脉络，讲述JavaWeb发展史。

---

背景

我们知道，搭建一个Web服务不仅需要动态资源的支持，还离不开静态资源的配合。而随着业务需求复杂度的提升，Java Web 开发经历了从前后端不分离到前后端分离的转变。

前后端不分离的时代

Java的response对象

Java可以通过response对象将动态内容和静态资源相结合渲染成最终的HTML页面，如果仅仅只是几行代码还好，但实际的业务里我们可能要写几百上千行这样的代码，这就非常麻烦了。

JSP技术的出现

为了减少写重复的response对象的代码，JSP出现了。在jsp里可以直接写html标签，而该写动态内容的地方也可以用java代码展示。

jsp原理

jsp本质是一个servlet。servlet是JavaEE定义的规范，一个Java类想被外界访问，必须实现Servlet接口。

证明jsp本质是一个servlet：

浏览器访问一个部署在tomcat的jsp文件后，会在tomcat的work目录下生成对应的java文件和字节码文件。

这个类继承了HttpJspBase，而HttpJspBase其父类又是HttpServlet，足以证实JSP本质是一个servlet。

而在HttpJspBase中的service方法，它干了什么事呢？其实就是把html标签输出到页面上了，也就是帮我们自动干了些活。

伴随着JSP的小技术

jsp的前后端未分离的时代中，java代码开发还有一些过渡使用的一些小技术：el表达式，jstl标签等，都是为了进一步简化jsp的开发。

再之后就要从mvc这种软件设计规范的角度继续聊下去web了。

过渡时代

Model 1 时代

在 Model1 模式下，整个 Web 应用几乎全部用 JSP 页面组成，jsp中混杂各种代码非常维护，它只用了少量的 JavaBean 来处理数据库连接、访问等操作。

这个模式下 JSP 即是控制层（Controller）又是表现层（View）。显而易见，这种模式存在很多问题。比如控制逻辑和表现逻辑混杂在一起，导致代码重用率极低；再比如前端和后端相互依赖，难以进行测试维护并且开发效率极低。

Model 2 时代

“Java Bean(Model)+ JSP（View）+Servlet（Controller） ”这种开发模式，这就是早期的 JavaWeb MVC 开发模式。

• Model:系统涉及的数据，也就是 dao 和 bean。
• View：展示模型中的数据，只是用来展示。
• Controller：接受用户请求，并将请求发送至 Model，最后返回数据给 JSP 并展示给用户

Model2 模式下还存在很多问题，Model2 的抽象和封装程度还远远不够，使用 Model2 进行开发时不可避免地会重复造轮子，这就大大降低了程序的可维护性和复用性。

于是，很多 JavaWeb 开发相关的 MVC 框架应运而生比如 Struts2，但是 Struts2 比较笨重。

Spring MVC的前后端不分离时代

随着 Spring 轻量级开发框架的流行，Spring 生态圈出现了 Spring MVC 框架， Spring MVC 是当前最优秀的 MVC 框架。相比于 Struts2 ， Spring MVC 使用更加简单和方便，开发效率更高，并且 Spring MVC 运行速度更快。

MVC 是一种设计模式，Spring MVC 是一款很优秀的 MVC 框架。Spring MVC 可以帮助我们进行更简洁的 Web 层的开发，并且它天生与 Spring 框架集成。Spring MVC 下我们一般把后端项目分为 Service 层（处理业务）、Dao 层（数据库操作）、Entity 层（实体类）、Controller 层(控制层，返回数据给前台页面)。

Spring MVC其实也有过前后端不分离的传统年代，接下来就从@RestController和@Controller这两个注解的区别来见证SpringMVC是怎么从不分离走向分离的。

单独使用 @Controller 不加 @ResponseBody的话一般使用在要返回一个视图的情况，这种情况属于比较传统的Spring MVC 的应用，对应于前后端不分离的情况。

Spring MVC的前后端分离时代

@RestController 返回JSON 或 XML 形式数据

@RestController只返回对象，对象数据直接以 JSON 或 XML 形式写入 HTTP 响应(Response)中，这种情况属于 RESTful Web服务，这也是目前日常开发所接触的最常用的情况（前后端分离）。

而@RestController其实是一个组合注解

如果你需要在Spring4之前开发 RESTful Web服务的话，你需要使用@Controller 并结合@ResponseBody注解，也就是说@Controller +@ResponseBody= @RestController（Spring 4 之后新加的注解）。

@ResponseBody 注解的作用是将 Controller 的方法返回的对象通过适当的转换器转换为指定的格式之后，写入到HTTP 响应(Response)对象的 body 中，通常用来返回 JSON 或者 XML 数据，返回 JSON 数据的情况比较多。

感受下区别

@Controller
public class HelloController {
    @PostMapping("/hello")
    @ResponseBody
    public Person greeting(@RequestBody Person person) {
        return person;
    }

}

@RestController
public class HelloController {
    @PostMapping("/hello")
    public Person greeting(@RequestBody Person person) {
        return person;
    }

}

从技术发展把握前后端分离的趋势

最初的web服务没有那么复杂，访问量也没那么大，服务端将页面渲染出来展示给用户也没什么压力。

比如最初的jsp，混杂着HTML、JS、Java、JSTL、EL等多种标签和语言，当业务复杂后，这种代码毫无设计可言，不同层级的逻辑耦合严重，难以迭代和维护。

接下来登场的是模板引擎，比如Velocity、Freemaker，它们就是在运行时生成一个上下文容器，前后端可以通过这个容器来进行数据通信

大约在2015之前，web项目的前后端通常是不分离的，那时候的前端真的就是切图的工具人，工作主要就是用html和css还原设计稿，最多就是用jQuery做几个页面效果。页面做好后就交给后端，接下来后端程序员使用模板语法，在前端们做的网页中绑定动态的数据。这就是前后端不分离，用模板嵌套方式绑定数据的时代。

随着项目���杂度的提升，这样不太合适。同一个文件，页面出问题前端改，数据出问题后端改，耦合太高，于是前后端分离的概念深入人心。而后端方面的SSM，前端的Vue和React的出现加速了前后端分离这一过程。

同步和异步请求

前后端定一个数据接口，然后前端写前端，后端写后端。前端要显示数据的时候，就用ajax发送请求向后台拿数据。

从同步和异步请求的角度看前后端分离的趋势

什么是同步请求

同步请求即是当前发出请求后，浏览器什么都不能做，必须得等到请求完成返回数据之后，才会执行后续的代码。也就是说，当发出同步请求后会把页面里所有的代码停止加载，页面处于一个假死状态，当这请求执行完毕后才会继续运行其他代码页面解除假死状态。

什么是异步请求

异步请求就当发出请求的同时，浏览器可以继续做任何事，Ajax发送请求并不会影响页面的加载与用户的操作，相当于是在两条线上，各走各的，互不影响。

异步请求可以完全不影响用户的体验效果，无论请求的时间长或者短，用户都在专心的操作页面的其他内容，并不会有等待的感觉。

既然异步这么好，同步存在还有什么意义？

那么，同步适用于一些什么情况呢？

我们可以想一下，同步是一步一步来操作，等待请求返回的数据，再执行下一步，那么一定会有一些情况，只有这一步执行完，拿到数据，通过获取到这一步的数据来执行下一步的操作。这是异步没有办法实现的，因此同步的存在一定有他存在的道理。

传统的web应用允许用户填写表单(form)，当提交表单时就向web服务器发送一个请求。服务器接收并处理传来的表单，然后返回一个新的网页。这个做法浪费了许多带宽，因为在前后两个页面中的大部分HTML代码往往是相同的。由于每次应用的交互都需要向服务器发送请求，应用的响应时间就依赖于服务器的响应时间。这导致了用户界面的响应比本地应用慢得多。

与此不同，AJAX应用可以仅向服务器发送并取回必需的数据，因此在服务器和浏览器之间交换的数据大量减少，结果我们就能看到响应更快的应用。同时很多的处理工作可以在发出请求的客户端机器上完成，所以Web服务器的处理时间也减少了。

使用Ajax的最大优点，就是能在不更新整个页面的前提下维护数据。这使得Web应用程序更为迅捷地回应用户动作，并避免了在网络上发送那些没有改变过的信息。

---

引用

Ajax同步与异步优缺点与使用 – 前端极客 – 博客园

【前端】前后端到底是什么？为什么要分离？_哔哩哔哩_bilibili

@RestController vs @Controller

前后端分离与前后端不分离，有什么区别和优劣？【晓舟报告】_哔哩哔哩_bilibili

原文链接: https://juejin.cn/post/7393312386345844751

文章标签

后端开发程序员