首页>>后端>>Spring->springboot入门菜鸟教程(spring boot入门)

springboot入门菜鸟教程(spring boot入门)

时间:2023-12-02 本站 点击:0

从零开始学SpringBoot之SpringBoot WebSocket原理篇

前言:

     这节我们介绍下WebSocket的原理。

一、websocket与http

WebSocket是HTML5出的协议,也就是说HTTP协议没有变化,或者说没关系,但HTTP是不支持持久连接的(长连接,循环连接的不算)

首先HTTP有 1.1 和 1.0 之说,也就是所谓的 keep-alive ,把多个HTTP请求合并为一个,但是 Websocket 其实是一个新协议,跟HTTP协议基本没有关系,只是为了兼容现有浏览器的握手规范而已,也就是说它是HTTP协议上的一种补充,可以通过这样一张图理解:

有交集,但是并不是全部。

另外Html5指的是一系列新的API,或者说新规范,新技术。Http协议本身只有1.0和1.1,而且跟Html本身没有直接关系。通俗来说,你可以用HTTP协议传输非Html数据。

二、Websocket是什么样的协议,具体有什么优点

首先,Websocket是一个持久化的协议,相对于HTTP这种非持久的协议来说。

HTTP的生命周期通过 Request 来界定,也就是一个 Request 一个 Response ,那么在 HTTP1.0 中,这次HTTP请求就结束了。

在HTTP1.1中进行了改进,使得有一个keep-alive,也就是说,在一个HTTP连接中,可以发送多个Request,接收多个Response。但是请记住 Request = Response, 在HTTP中永远是这样,也就是说一个request只能有一个response。而且这个response也是被动的,不能主动发起。

跟Websocket有什么关系呢?

首先Websocket是基于HTTP协议的,或者说借用了HTTP的协议来完成一部分握手。

首先我们来看个典型的 Websocket 握手(借用Wikipedia的。。)

GET /chat HTTP/1.1

Host: server.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

Origin:

熟悉HTTP的童鞋可能发现了,这段类似HTTP协议的握手请求中,多了几个东西。我会顺便讲解下作用。

2.1 Upgrade 和Connection

Upgrade: websocket

Connection: Upgrade

这个就是Websocket的核心了,告诉 Apache 、Tomcat、 Nginx 等服务器:注意啦,我发起的是Websocket协议,快点帮我找到对应的助理处理~不是那个老土的HTTP。

2.2 Sec-WebSocket

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

首先, Sec-WebSocket-Key是一个 Base64 encode 的值,这个是浏览器随机生成的,告诉服务器:你妹,不要忽悠窝,我要验证尼是不是真的是Websocket助理。

然后, Sec_WebSocket-Protocol是一个用户定义的字符串,用来区分同URL下,不同的服务所需要的协议。简单理解:今晚我要服务A,别搞错啦~

最后, Sec-WebSocket-Version是告诉服务器所使用的 WebSocket Draft (协议版本),在最初的时候,Websocket协议还在 Draft 阶段,各种奇奇怪怪的协议都有,而且还有很多期奇奇怪怪不同的东西,什么Firefox和Chrome用的不是一个版本之类的,当初Websocket协议太多可是一个大难题。。不过现在还好,已经定下来啦~大家都使用的一个东西~ 脱水:服务员,我要的是13岁的噢→_→

然后服务器会返回下列东西,表示已经接受到请求,成功建立Websocket啦!

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

Sec-WebSocket-Protocol: chat

这里开始就是HTTP最后负责的区域了,告诉客户,我已经成功切换协议啦~

Upgrade: websocket

Connection: Upgrade

依然是固定的,告诉客户端即将升级的是 Websocket 协议,而不是mozillasocket,lurnarsocket或者shitsocket。

然后, Sec-WebSocket-Accept这个则是经过服务器确认,并且加密过后的 Sec-WebSocket-Key 。服务器:好啦好啦,知道啦,给你看我的ID CARD来证明行了吧。后面的, Sec-WebSocket-Protocol 则是表示最终使用的协议。

至此,HTTP已经完成它所有工作了,接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。

—————— 技术解析部分完毕 ——————

你说了这么久,那到底Websocket有什么鬼用, http long poll ,或者ajax轮询 不都可以实现实时信息传递么。

好好好,年轻人,那我们来讲一讲Websocket有什么用。来给你吃点胡(苏)萝(丹)卜(红)

三、Websocket的作用

在讲Websocket之前,我就顺带着讲下 long poll 和 ajax轮询 的原理。

3.1 ajax 轮询

ajax轮询的原理非常简单,让浏览器隔个几秒就发送一次请求,询问服务器是否有新信息。

场景再现:

客户端:啦啦啦,有没有新信息(Request)

服务端:没有(Response)

客户端:啦啦啦,有没有新信息(Request)

服务端:没有。。(Response)

客户端:啦啦啦,有没有新信息(Request)

服务端:你好烦啊,没有啊。。(Response)

客户端:啦啦啦,有没有新消息(Request)

服务端:好啦好啦,有啦给你。(Response)

客户端:啦啦啦,有没有新消息(Request)

服务端:。。。。。没。。。。没。。。没有(Response) —- loop

3.1  长轮询(long poll)

long poll 其实原理跟 ajax轮询 差不多,都是采用轮询的方式,不过采取的是阻塞模型(一直打电话,没收到就不挂电话),也就是说,客户端发起连接后,如果没消息,就一直不返回Response给客户端。直到有消息才返回,返回完之后,客户端再次建立连接,周而复始。

场景再现:

客户端:啦啦啦,有没有新信息,没有的话就等有了才返回给我吧(Request)

服务端:额。。等待到有消息的时候。。来给你(Response)

客户端:啦啦啦,有没有新信息,没有的话就等有了才返回给我吧(Request) -loop

从上面可以看出其实这两种方式,都是在不断地建立HTTP连接,然后等待服务端处理,可以体现HTTP协议的另外一个特点,被动性。

何为被动性呢,其实就是,服务端不能主动联系客户端,只能有客户端发起。

简单地说就是,服务器是一个很懒的冰箱(这是个梗)(不会、不能主动发起连接),但是上司有命令,如果有客户来,不管多么累都要好好接待。

说完这个,我们再来说一说上面的缺陷(原谅我废话这么多吧OAQ)

从上面很容易看出来,不管怎么样,上面这两种都是非常消耗资源的。

ajax轮询需要服务器有很快的处理速度和资源。(速度)long poll 需要有很高的并发,也就是说同时接待客户的能力。(场地大小)

所以 ajax轮询 和 long poll 都有可能发生这种情况。

客户端:啦啦啦啦,有新信息么?

服务端:月线正忙,请稍后再试(503 ServerUnavailable)

客户端:。。。。好吧,啦啦啦,有新信息么?

服务端:月线正忙,请稍后再试(503 ServerUnavailable)

客户端:然后服务端在一旁忙的要死:冰箱,我要更多的冰箱!更多。。更多。。(我错了。。这又是梗。。)

3.2 WebSocket

通过上面这个例子,我们可以看出,这两种方式都不是最好的方式,需要很多资源。

一种需要更快的速度,一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高。

哦对了,忘记说了HTTP还是一个状态协议。

通俗的说就是,服务器因为每天要接待太多客户了,是个健忘鬼,你一挂电话,他就把你的东西全忘光了,把你的东西全丢掉了。你第二次还得再告诉服务器一遍。

所以在这种情况下出现了,Websocket出现了。他解决了HTTP的这几个难题。首先,被动性,当服务器完成协议升级后(HTTP-Websocket),服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。

客户端:啦啦啦,我要建立Websocket协议,需要的服务:chat,Websocket协议版本:17(HTTP Request)

服务端:ok,确认,已升级为Websocket协议(HTTPProtocols Switched)

客户端:麻烦你有信息的时候推送给我噢。。

服务端:ok,有的时候会告诉你的。

服务端:balabalabalabala

服务端:balabalabalabala

服务端:哈哈哈哈哈啊哈哈哈哈

服务端:笑死我了哈哈哈哈哈哈哈

就变成了这样,只需要经过一次HTTP请求,就可以做到源源不断的信息传送了。(在程序设计中,这种设计叫做回调,即:你有信息了再来通知我,而不是我傻乎乎的每次跑来问你)

这样的协议解决了上面同步有延迟,而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢?

其实我们所用的程序是要经过两层代理的,即HTTP协议在Nginx等服务器的解析下,然后再传送给相应的Handler(PHP等)来处理。简单地说,我们有一个非常快速的 接线员(Nginx) ,他负责把问题转交给相应的 客服(Handler) 。

本身接线员基本上速度是足够的,但是每次都卡在客服(Handler)了,老有客服处理速度太慢。,导致客服不够。Websocket就解决了这样一个难题,建立后,可以直接跟接线员建立持久连接,有信息的时候客服想办法通知接线员,然后接线员在统一转交给客户。这样就可以解决客服处理速度过慢的问题了。

同时,在传统的方式上,要不断的建立,关闭HTTP协议,由于HTTP是非状态性的,每次都要重新传输 identity info (鉴别信息),来告诉服务端你是谁。

虽然接线员很快速,但是每次都要听这么一堆,效率也会有所下降的,同时还得不断把这些信息转交给客服,不但浪费客服的处理时间,而且还会在网路传输中消耗过多的流量/时间。

但是Websocket只需要一次HTTP握手,所以说整个通讯过程是建立在一次连接/状态中,也就避免了HTTP的非状态性,服务端会一直知道你的信息,直到你关闭请求,这样就解决了接线员要反复解析HTTP协议,还要查看identity info的信息。

同时由客户主动询问,转换为服务器(推送)有信息的时候就发送(当然客户端还是等主动发送信息过来的。。),没有信息的时候就交给接线员(Nginx),不需要占用本身速度就慢的客服(Handler)了

至于怎么在不支持Websocket的客户端上使用Websocket。。答案是:不能。但是可以通过上面说的 long poll 和 ajax 轮询 来 模拟出类似的效果

看完让你彻底搞懂Websocket原理

内容转自知乎:

如果觉得文字不过瘾,可以通过视频学习SpringBoot,这里给大家推荐

《从零开始学SpringBoot》视频教程链接:

【  Java全栈技术分享 】,Jacky。

学妹想学SpringBoot,连夜整理一篇SpringBoot入门最详细教程笔记

凭借开箱即用,远离繁琐的配置等特性,Spring Boot 已经成为 Java 开发者人人必学必会的开源项目。那么开发者该如何快速上手Spring Boot 呢?

那请问Spring Boot 到底是啥?Spring Boot是Spring框架的扩展和自动化,它消除了在Spring中需要进行的XML(EXtensible Markup Language)文件配置(若习惯XML配置,则依然可以使用),使得开发变得更快、更高效、更自动化。

微服务:每一个功能元素最终都是一个可独立替换和独立升级的软件单元。

在maven 的settings.xml配置文件的profiles标签添加以下配置:

把maven整合到idea。

项目目录:

HelloWorldMainApplication:

HelloController:

运行结果:

打开浏览器访问:

1、我们在pom.xml文件中假如以下代码:

2、然后,我们将应用打包

3、然后再target文件夹下就可以看到 spring-boot-01-helloworld-1.0-SNAPSHOT.jar

4、复制到桌面(随便哪,个人选择),打开cmd窗口,切换到jar包所在位置,我的是桌面,然后输入: java -jar spring-boot-01-helloworld-1.0-SNAPSHOT.jar ,运行效果如下。

5、打开浏览器访问:,同样可以看到HelloWord

这样的部署就变得十分简单了。

小伙伴们,帮忙一键三连呀

题外话,我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在Java学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多程序员朋友无法获得正确的资料得到学习提升

故此将并 将重要的Java进阶资料包括并发编程、JVM调优、SSM、设计模式、spring等知识技术、阿里面试题精编汇总、常见源码分析等录播视频免费分享出来,需要领取的麻烦 评论区领取

【springboot 入门篇】第3篇 从controller开始学起

在写web项目的时候,controller里的返回值一般分为两种,一种是返回页面,也就是ModeAndView,另一种是直接返回数据,比如json格式的数据。

返回一个页面,我们需要用到一些模板引擎,比如熟知的jsp,模板引擎后面会详细讲解。

返回数据一般会选择返回json数据,我们之前的demo项目中使用的@RestController就是一个返回数据的注解。

spring-boot 支持多种模版引擎包括:

我们在讲前后端分离之前,都会使用Thymeleaf模板引擎,先简单的介绍一下它。

Thymeleaf是一个java类库,它是一个xml/xhtml/html5的模板引擎,可以作为mvc的web应用的view层。

Thymeleaf还提供了额外的木块与spring mvc集成,所以使用ssm框架的也可以使用这个模板引擎。

接下来,我们通过一个项目,来实践一下两种不同的返回结果。

先看一下最终的目录结构:

这里我们使用了Thymeleaf模板引擎来获得后台传来的数据并解析,使用bootstrap框架显示数据。可以看到,Thymeleaf的用法和jsp还是有点像的。可以直接通过${}的形式来获得attribute中的数据。

可以看到,我们成功的在前端获取到了数据。方式就是将数据保存在attribute中,然后再前端页面获取。

我们修改了注解,发现结果变了,直接显示了“index”,是因为@RestController会直接返回数据,而不是渲染页面,所以直接返回了index(这个index,是return语句中的)

访问

获得了json格式的数据

访问

列表也可以直接渲染为json。

访问

访问

会发现这两个都报错了,因为@Controller注解是渲染视图的,而我们返回的是对象或者集合,不能完成正常的渲染。

本文主要讲解了spring boot 如何渲染视图和数据,讲解了@Controller和@RestController的区别与用法。如果有什么疑问,请及时联系我。

我之前写过一个重新认识java系类(还没写完,会写完的。。),篇幅很长,每一篇文章多的有7、8千字,和多人抱怨说看到一半就不想看了,因为太长了,所以 spring boot 这个系类会尽量的短小精悍,每篇文章只讲一个知识点,这样看着不累~

15《Spring Boot 入门教程》多数据源与分布式事务

一个项目中使用多个数据源的需求,我们在日常工作中时常会遇到。

以商城系统为例,有一个 MySQL 的数据库负责存储交易数据。公司还有一套 ERP 企业信息化管理系统,要求订单信息同步录入 ERP 数据库,便于公司统一管理,而该 ERP 系统采用的数据库为 SQL Server 。

此时,就可以在 Spring Boot 项目中配置多个数据源。另外,使用多数据源后,需要采用分布式事务来保持数据的完整性。

本小节我们使用 Spring Boot 开发一个商城系统的订单生成功能,订单信息同时进入 MySQL 与 SQL Server 数据库。

首先创建 MySQL 数据库 shop ,并新建订单表 order ,表结构如下:

order 表结构

然后创建 SQL Server 数据库 erpshop ,并新建订单表 erp_order ,表结构如下。注意 id 是自增长的唯一标识,out_id 是对应订单在 MySQL 数据库中的唯一标识,以便在两个库中比对订单。

erp_order 结构

接下来,我们开始实现 Spring Boot 后端项目,数据持久层采用 MyBatis 框架,同时访问两个数据源。

Spring Boot 版本选择 2.2.5 ,Group 为 com.imooc , Artifact 为 spring-boot-multidb,生成项目后导入 Eclipse 开发环境。

我们引入热部署依赖、 Web 依赖、数据库访问相关依赖及测试相关依赖,具体如下:

实例:

由于我们要同时访问两个数据库,所以需要在配置文件中添加两个数据源的配置信息。注意配置多数据源时, url 配置需要使用 spring.datasource.db1.jdbc-url=xxx 的形式。

实例:

多个数据源的情况下, 我们需要通过配置类,将数据源注册为组件放入 Spring 容器中。

实例:

通过这个配置类, Spring 容器中就有两个数据源组件,这两个组件分别采用 spring.datasource.db1 和 spring.datasource.db2 开头的配置信息。所以通过这两个组件,就能分别操作 MySQL 数据源 1 和 SQL Sever 数据源 2 。

多数据源情况下, MyBatis 中的关键组件 SqlSessionFactory 和 SqlSessionTemplate 也需要单独配置,我们需要为两个数据源分别配置一套组件。

实例:

通过上面的配置类, com.imooc.springbootmultidb.mapper1 包中的 DAO 数据访问接口会自动调用 sqlSessionTemplate1 组件实现具体数据库操作,而 sqlSessionTemplate1 操作的数据源已经通过配置类设置为 db1 。同时, DAO 数据访问接口对应的映射文件已经指定到 classpath:mapper1/ 目录去寻找。这样数据源 – DAO 数据访问接口 – 映射文件三者的对应关系就建立起来了。

数据源 2 的配置方法是一样的, com.imooc.springbootmultidb.mapper2 包中的 DAO 数据访问接口会自动调用 sqlSessionTemplate2 组件,其操作的数据源即为 db2 ,其对应的映射文件指定到 classpath:mapper2/ 目录去寻找。

实例:

数据访问接口的位置已经在配置类指定,首先在 com.imooc.springbootmultidb.mapper1 创建 OrderDao ,操作的是数据源 1 中的 order 表。

实例:

然后在 com.imooc.springbootmultidb.mapper2 创建 ErpOrderDao ,操作的是数据源 2 中的 erporder 表。

实例:

这两个接口中使用的数据对象比较简单,代码如下:

实例:

分别针对 OrderDao 、 ErpOrderDao 编写对应的映射文件,然后按照配置类指定的位置,两个文件分别放到 resources/mapper1 和 resources/mapper2 目录下。

实例:

实例:

数据操作接口与对应的映射文件均已编写完毕,现在可以通过测试类进行多数据源测试了,我们在测试类中同时向两个库插入记录。

实例:

运行测试方法后,两个数据库表中均新增数据成功,这样我们就成功的使用 Spring Boot 同时操作了两个数据源。

采用多数据源之后,事务的实现方式也随之发生变化。当某个数据源操作出现异常时,该数据源和其他数据源的事务都需要回滚。这种涉及多个数据源的事务,称为分布式事务,接来下我们就来具体实现一下。

在 pom.xml 引入 Atomikos 事务管理器相关的依赖项, Atomikos 是一个开源的事务管理器,支持分布式事务。

实例:

需要将默认的数据源更换为支持分布式事务的数据源, MySQL 对应的数据源为 MysqlXADataSource , SQL Server 对应的数据源为 SQLServerXADataSource 。

实例:

继续修改 DataSourceConfig 类,在其中配置分布式事务管理器组件。当项目中使用事务时,会通过配置的分布式事务管理器管理分布式事务操作。

实例:

在测试方法上添加 @Transactional 开启事务,然后在两个数据源操作中间模拟抛出异常。

实例:

此时运行测试类,可以发现数据源 1 的事务已回滚,验证成功!

在开发 Spring Boot 项目时,如果默认配置满足不了我们的需求,可以通过手工配置组件实现我们需要的功能。这些组件可能是各个公司提供的,我们根据相应文档,为其配置各个属性即可。

04《Spring Boot 入门教程》使用模板引擎开发 Web 项目

模板引擎这个词,咋听起来,有点高大上的意味。

实际上,模板引擎是非常平易近人的技术。譬如大家可能都比较熟悉的 JSP ,就是一种比较典型的模板引擎。

当浏览器将请求抛给控制器,控制器处理好数据后,就跳转 JSP 等模板引擎页面。注意在跳转的同时,还会将数据组装好,也交给模板引擎处理。

模板引擎会根据数据,和模板引擎的规则,动态生成 HTML 页面,最后返回给浏览器显示。

我们使用 Spring Boot 开发 Web 项目,大体上有两种方式。

第一种方式,是后端服务化的方式,也是当前的主流方式。前端是静态的 HTML 页面,通过 Ajax 请求 Spring Boot 的后端接口。 Spring Boot 返回数据一般采用 JSON 格式,前端接收后将数据显示。

第二种方式,是采取模板引擎的方式。前端的请求,到达 Spring Boot 的控制器后,控制器处理请求,然后将返回数据交给模板引擎。模板引擎负责根据数据生成 HTML 页面,最后将 HTML 返回给浏览器。

我个人比较推荐第一种方式,说一下该方式的几个优点:

本篇是讲模板引擎,也得说说模板引擎的优点,王婆卖瓜不能光夸草莓啊。模板引擎开发的页面,对搜索引擎 SEO 比较友好;还有就是简单的页面,如果用模板引擎开发速度比较快,毕竟模板化的方法,目的就是减少重复提高效率。

Spring Boot 支持的模板引擎种类很多,常见的有 FreeMarker 、 Thymeleaf 、 JSP 。

因为这些模板引擎使用的用户都不少,所以我们逐一介绍下其实现过程。

至于孰优孰劣,请各位看官自行评价。正所谓:尺有所短,寸有所长,各取所爱,万物生长!

本篇我们开发一个商品浏览项目实例。

此处说一个我个人的经验:在做一个项目或一个模块的时候,不要一开始就动手写代码,最好是谋定而后动。

我们作为程序员,实际上是整个程序世界的总指挥。应该先整体规划,再实现局部。这种总分型的开发方法便于我们理顺思路,提高编码效率!

好的,我们来思考下,实现商品浏览项目实例的整体流程:

整体流程

可以看到,我们是先建立了控制器方法和页面,再去实现其中的具体细节。这样可以让我们的思维保持连贯性和整体性,在做一些页面和方法较多的项目时,会感觉更加顺畅。

我们按整体流程,使用 FreeMarker 模板引擎,来实现商品浏览功能。

使用 Spring Initializr 创建项目,Spring Boot 版本选择 2.2.5 , Group 为 com.imooc , Artifact 为 spring-boot-freemarker ,生成项目后导入 Eclipse 开发环境。

引入 Web 项目及 FreeMarker 模板相关的依赖项,代码如下:

实例:

创建控制器类,由于是商品相关的控制器,所以命名为 GoodsController ,代码如下:

实例:

我们具体解释下该类的作用。

我们 resource/templates 目录下新建商品页面 goods.ftl ,先不必实现具体功能,代码如下:

实例:

此时我们启动项目,然后访问 ,即可显示对应页面内容。

定义商品类 GoodsDo 用来描述商品信息,注意 Do 表示数据模型对象(Data Object),代码如下:

实例:

然后我们编写服务类 GoodsService ,提供获取商品列表的方法。注意此处仅仅是演示模板引擎,并不需要访问数据库,直接返回一个指定内容的商品列表。

实例:

此时,我们的控制器就可以注入 GoodsService 类型的组件,然后调用其方法了。

实例:

注意 model.addAttribute("goodsList", goodsService.getGoodsList()); ,我们将商品列表相关的数据交给模板引擎去处理。

此时我们可以根据 FreeMarker 模板引擎,按模板规则显示商品信息了。

实例:

注意我们通过 FreeMarker 的模板语法,输出了商品列表信息。关于 FreeMarker 模板引擎更多的语法规则,感兴趣的同学可以后续查阅更多资料。

启动项目,打开浏览器访问 ,即可查看输出结果。

Thymeleaf 和 FreeMarker ,都是模板引擎,使用方法基本类似。此处我们仅仅是给出一个范例,不再做过多的解释。

使用 Spring Initializr 创建项目, Spring Boot 版本选择 2.2.5 , Group 为 com.imooc , Artifact 为 spring-boot-thymeleaf ,生成项目后导入 Eclipse 开发环境。

引入 Web 项目及 Thymeleaf 模板相关的依赖项。

实例:

创建控制器类, GoodsController , Thymeleaf 直接使用 HTML 作为模板页面,故代码如下:

实例:

我们在 resource/templates 目录下新建商品页面 goods.html ,先不必实现具体功能,代码如下:

实例:

此时我们启动项目,然后访问 ,即可显示对应页面内容。

商品类 GoodsDo ,服务类 GoodsService ,这两个类与上面没有区别直接放出代码。

实例:

实例:

好的,此时我们的控制器就可以注入 GoodsService 类型的组件,然后调用其方法了。

实例:

此时我们可以根据 Thymeleaf 模板引擎,按模板规则显示商品信息了。

实例:

注意我们通过 Thymeleaf 的模板语法,输出了商品列表信息。关于 Thymeleaf 模板引擎更多的语法规则,感兴趣的同学可以后续查阅更多资料。

启动项目,打开浏览器访问 ,即可查看输出结果。

到此,大家基本上也能发现,这两种方式除了模板页面文件内容不同,其他地方基本都是一模一样的。

也就是说,模板引擎主要负责通过一些模板标签,将控制器返回的数据解析为网页。

注意 Spring Boot 官方已经不推荐使用 JSP 了,确实操作起来也比较麻烦。但是由于 JSP 用户体量还是比较大的,所以此处还是简单演示下,开发步骤与 FreeMarker / Thymeleaf 基本一致。

使用 Spring Initializr 创建项目, Spring Boot 版本选择 2.2.5 , Group 为 com.imooc , Artifact 为 spring-boot-jsp ,生成项目后导入 Eclipse 开发环境。

引入 Web 项目及 JSP 模板相关的依赖项。

实例:

创建控制器类, GoodsController ,代码如下:

实例:

手工添加 src/main/webapp 及子目录如下,同时目录下放一个 goods.jsp 用于测试。注意该目录是一个 Source Folder 源代码目录,不是普通文件夹目录。

spring-boot-jsp 项目结构

实例:

注意,我们还需要添加一个视图解析器,实现 JSP 页面往指定目录跳转。

实例:

此时我们启动项目,然后访问 ,即可显示对应页面内容。

商品类 GoodsDo ,服务类 GoodsService ,这两个类与上面没有区别直接放出代码。

实例:

实例:

好的,此时我们的控制器就可以注入 GoodsService 类型的组件,然后调用其方法了。

实例:

此时我们可以根据 JSP 模板引擎,按模板规则显示商品信息了。

实例:

注意我们通过 JSP 的模板语法,输出了商品列表信息。关于 JSP 模板引擎更多的语法规则,感兴趣的同学可以后续查阅更多资料。

启动项目,打开浏览器访问 ,即可查看输出结果。

最后大家应该也发现了, FreeMarker 和 Thymeleaf 的用法几乎是一模一样的,而 JSP 还需要手工添加一些目录和配置。

三种方式各有优劣, FreeMarker 模板语法比较简洁, Thymeleaf 可以直接使用 HTML 作为模板文件, JSP 用户群体广泛。

但是三种方式,都是一种模板引擎而已,将控制器返回数据转化为 HTML 页面显示,本质上没啥区别,大家对模板引擎有一个了解即可。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/Spring/9998.html