Java项目笔记

目录

一、交流平台

第一章

1.开发社区首页

一、新建了三个类:

1.DiscussPost:用户的帖子。

属性: id(自动生成主键),用户 id(外键连接 user 表),帖子的主题 ,帖子内容,帖子类型(普通,置顶),帖子状态(正常,精华,拉黑),帖子的创建时间 ,评论数量, 帖子分数(给帖子排名,按热度)。

2.Page:为了分页。

属性:有当前页码,显示上限,数据总数(用于计算总页数),查询路径(用于复用分页链接),拥有获取当前页起始行、总页数、获取下面页码的起始页码和结束页码方法。

3.User:用户类。

Service: 通过 user id 得到 user 对象。

二、Controller 层

处理网页的查询请求可以通过注解注入 DiscussPost Service 来解决,但 DiscussPost Service 只能返回 DiscussPost 列表,但列表中没有 user 属性,只有 user id(我们一般看到的讨论网页是能看到 user 的) 所以我们还需要注入 UserService 来得到 user 对象,将 user和 discussPost 通过list<map<string,object(DiscussPost)>>放在一起,map 中有<“post”,DiscussPost >和<”user”,user>,将此 list 传给 model,网页模板有 thymeleaf。

为了分页:在模板中配置相对应的方法 首页(末页)路径、第几页 达到首页之后上
一页的按钮不可点(末页同理) 显示的页码范围。

第二章

2.发送邮件功能

①在新浪中将想要作为发送方的邮箱设置 SMTP 服务为开启,通过 Maven 导入 springboot mail
的 jar 包,在配置文件中配置域名、端口、发送邮件的账号、密码等,通过 JavaMailSender发送邮件。

②为了能够将发送邮件的逻辑复用,创建 MailClient(因为要调用新浪的服务,所以我们是客户端)类来封装 JavaMailSender(有两种方法:发送邮件主体,创造邮件主体),先通过 JavaMailSender 来创建空的邮件主体之后用 spring 提供的 MimeMessageHelper 帮助类来丰富我们的邮件主体(发件人(配置文件中配置好了),收件人(方法中传入的参数),主题(方法中传入的参数),内容(方法中传入的参数)),之后再通过 JavaMailSender 的 send 方法发送邮件。

③使用 Thymeleaf 发送 html 文件:先创建 Thymeleaf 模板,将 model 和模板给模板引擎生成网
页(字符串类型),赋给发送邮件的内容参数。

Thymeleaf是一个现代服务器端Java模板引擎,适用于Web和独立环境,能够处理HTML,XML,JavaScript,CSS甚至纯文本。
Thymeleaf的主要目标是提供一种优雅且高度可维护的模板创建方式。为实现这一目标,它以自然模板的概念为基础,将其逻辑注入模板文件,其方式不会影响模板被用作设计原型。这改善了设计沟通,缩小了设计和开发团队之间的差距。

3.回话管理

在这里插入图片描述

Http 的两个成功执行的请求之间是没有关系的,需要通过 cookie 来解决问题,使得请求能共享相同的上下文信息,达成相同的状态。

cookie 是服务器发送到浏览器,并保存在浏览器端
的一小块数据,浏览器下次访问该服务器时,会自动携带块该数据,将其发送给服务器,一
个 cookie 只能保存一组 key,value,上图的四步为通常的 cookie 设置,最后的返回值是返回
给浏览器的字符串,非网址,是乱写的。
在这里插入图片描述
获得 cookie,注意 cookie 在@RequestMapping 中传入给了服务器,可以在响应体中通过@CookieValue(key 值) String code 来获得 cookie 中的某一值,全部获得 cookie 的话是个
数组。

Session - 是 JavaEE 的标准,用于在服务端记录客户端信息。 - 数据存放在服务端更加安
全,但是也会增加服务端的内存压力。

传 cookie 是为了能够查找到对应的session。
在这里插入图片描述
Session 是和 model 等类型一样,一经声明 spring mvc 自动注入

2.为何用 cookie 不用 session?

当浏览器发出请求,传给 nginx 代理,经过负载均衡,可能第一次的请求发给了服务器 1,服务器 1 存储了一份 session 返给浏览器一个 cookie(session id),之后第二次浏览器发出请求,经过反向代理可能给服务器 3 发送了此 cookie,但服务器 3 没有对应的 session,会新建一个 session,则此 session 和第一次的请求数据创建的 session 不一样,会造成数据错误,可以通过设置负载均衡的分配策略,一种是粘性 session,只要是同一个浏览器 ip 就固定的分配给同一个服务器处理,但这样就会很难保证服务器的负载是均衡的,负载不均衡,性能不好;

第二种策略是同步 session,当一个服务器创建了 session 后,会同步给每个服务器,首先一台服务器同步给其他很多服务器,会影响性能,而且服务器和服务器之间会产生耦合,产生关联,会影响部署;

第三种方案是共享 session,单独有一个服务器,专门存放 session,当需要获得 session 时,都去找此服务器,但这样如果这个服务器挂掉了,其他服务器没法工作,违背了分布式的初衷:解决性能瓶颈,如果将此服务器搞一个集群,那和方案二没有区别,仍然需要共享;目前主流方案是能将数据存放到 cookie 里就放到 cookie 里,敏感数据比如密码之类的,就放到 nosql 数据库里(关系型数据库会把数据存放到硬盘里,速度慢)

4.检查登录状态

用户如果知道功能路径可以通过超路径访问,但如果是一个需要登陆才能访问的路径,但你直接通过超访问路径访问的话,可能会造成问题,下面的例子是围绕未登录但直接访问账号设置功能来讨论。

自定义注解:
(1)常见的元注解:
@Target:声明自定义的注解可以写在哪个位置,作用在哪个类型上(定义在类、方法、属
性上)
@Retention:声明自定义注解保留的时间(有效的时间:编译时有效,运行时有效)
@Document:生成文档时是否将自定义注解也带上。
@Inherited:用于继承,子类继承一个父类,父类有自定义注解,子类是否要将注解继承。

(2)如何读取注解:
Method.getDeclaredAnnotations() 通过反射 Method 类型对象调用这个方法获取这个方法上所有的注解。Method.getAnnotation(Class annotationClass)尝试获取 annotation(注解)Class 类型的注解。

创建注解
在这里插入图片描述
作用域在方法上,有效的时间是程序运行时。
在这里插入图片描述
在想要拦截的方法上加上此注解。
在这里插入图片描述
定义拦截器,因为只需要拦截方法,所以先判断 handler 是否是拦截方法类型,从拦截方法中获取方法,通过反射得到方法的此注解类型的注解,判断只要拥有此注解的且 user 为空(还未登录)则返回登录页面,return false 不继续往下执行。
在这里插入图片描述
拦截器的使用范围,不拦截一些静态的东西,不用管拦截范围,按默认全局就可以,因为在定义拦截器的时候已经拥有了相关的逻辑,也可以像第一个拦截器定义域一样,添加定义域不按默认值,但这样的话太麻烦,因为可能有好多路径都需要添加,一个一个麻烦。

5.开发登录退出功能

1.访问登录页面:点击顶部区域内的链接,打开登录页面。

2.登录:验证账号、密码、验证码,成功时,生成登录凭证,发送给客户端,失败时,跳转回登录页,登录有一个登录凭证表,首先创建一个登录凭证实体类,在 dao 层创建用于与登录凭证表相连接的接口 , 通过注解来实现与 登 录 凭 证 表 连 接 ,如下图所 示
在这里插入图片描述
在 service 层,创建方法,返回值为 map 用于判断用户在传递过来的账号、密码是否正确、以及记住我选项(对应登录凭证表的存活时间):空值处理、验证账号、验证状态、验证密码(注意与 user 表中的保存密码不同,还需要加盐、加密才可以与数据库中的密码相同),通过 dao 生成登录凭证在 controller 层,检查验证码,通过 service 层来检查用户账号和密码,不正确返回登录页面,正确返回主页,且通过 cookie 把登录凭证里的 ticket 返给客户端。

3.退出:将登录凭证修改为失效状态,跳转至网站首页在 service 层通过 dao 层中的 updateStatus 方法将凭证改为失效状态,controller 层通过service 更改凭证,重定向到登录页面。

6.生成验证码

Kaptcha:现成的验证码工具

导入 jar 包,编写 Kaptcha 配置类,生成随机字符、生成图片。

导入 jar 包:从 maven 中导入 jar 包,编写 Kaptcha 配置类:因为 sring 没有整合 kaptcha,所以我们需要创建一个配置类(颜色字体 长 宽 高 , 有 哪 些 随 机 字 符 , 一 个 验 证 码 有 几 个 字 符 ), 去 整 合kaptcha。
在这里插入图片描述
主要看 properties
在这里插入图片描述
生成验证码:先生成文本,再将文本变成图片;因为此次请求只是将验证码图片传给页面,但当你点击登录时,会将此次的验证码文本与登录时输入的验证码文本作比较,所以两次请求有关联,是一次会话,且是敏感信息,要通过 session 来完成会话;之后要将图片输出给浏览器,首先声明你回应的类型是什么,之后开启输出流,将图片输出出去,spring mvc 会自动关闭输出流。

Ps:只要响应体不是字符串或网址,则方法返回空值,且将响应体当做参数传入方法中,进行操作

Ps:注意在模板中将验证码的路径改下,改成你验证码中的请求路径。

7.显示登录信息(拦截器)

在网页头部因为每个请求都需要判断显示的按钮(首页、登录、注册、消息、个人头像、),反 复 实 现 所 以 用 拦 截 器 处 理 , 逻 辑 如 下 图 所 示。在这里插入图片描述在这里插入图片描述
在请求给 controller 之前先拦截一次,获取请求的持有对象(因为 controller 层也可能会用到):通过 cookie 得到 ticket,之后用 ticket 通过登录表得到 userID,将这个 id 传给 ThrendLocal对 象 ( 为 了 防 止 线 程 冲 突 , 因 为 浏览 器 和 服 务 器 是 多 对 一 的 关 系 )。
在这里插入图片描述
在模板引擎之前再拦截一次,在 ThrendLocal中获取 user 对象传给 model在模板引擎之后拦截一次,将 ThrendLocal中的对象清理掉,减少内存。

8.用户注册功能

Ps:CommunityUtil 是自己写的类拥有生成随机字符串的方法(封装了 uuid)以及 MD5 加密方法。

可以将用户注册功能分为三个请求,访问注册页面,提交注册数据,激活注册账号(按请求来开发用户注册功能)

1.访问注册页面:在 controller 层编写响应方法,返回注册页面路径。

2.提交注册数据:通过 maven 导入 commons lang 的 jar 包,为了判断常用的数据是否空值,在UserService 层中编写一个注册方法,传入的参数类型为 user,返回值为 map 因为可能是某一字段不能为空,账号已存在等等信息。

首先对空值处理,判断 user 是否为 null,是的话抛出异常,在判断 user 里的属性是否为空,若为空将错误信息 put(key=“usernamemsg”,value=“账号不能为空” 等映射)进返回的 map 中,直接 ruturn map,若上述错误都没有判断 username、Email 是否重复,若重复 return,都没有问题,将用户设置的密码进行加密(通过 CommunityUtil设置 salt 与用户密码拼接在一起之后传入给 CommunityUtil 的加密方法)覆盖用户密码,将一些用户没有编写的属性赋值(type、status 等),赋给用户一个随机头像(应该传入路径参数,共有 1000 个随机头像,大体的路径相同,只有一个数字不同可以通过 rand

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值