CGB2005 0812 JAVA09

最新推荐文章于 2024-06-10 21:57:08 发布

qq_43765881

最新推荐文章于 2024-06-10 21:57:08 发布

阅读量102

点赞数 1

分类专栏：个人java总结文章标签： java

本文链接：https://blog.csdn.net/qq_43765881/article/details/107949163

版权

个人java总结专栏收录该内容

22 篇文章 0 订阅

订阅专栏

今早

复习回顾

在这里插入图片描述

9点10之前回看录像晚上

Spring中的v

handler=controller

自己的初步实现
在这里插入图片描述
1.entity pojo层

试着对着log表去建立

文档对应的private static final long serialVersionUID = 1L;
是什么
解释序列化id

规范 1.先把属性写完 2.加入序列化接口和对应序列化id

理解pojo需加入序列化就行
默认第二个
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

序列化源码分析

如下图 pojo日志模块这个类实现Serializable序列化配置缓存会用或者跨进程通讯的时候会用
目的为了掌握规范以后实现可扩展性

2.dao层数据持久层
上午10.20前漏了点初开讲的(over)

在这里插入图片描述
第二步
统计总数的接口设计

第三步
在这里插入图片描述

在这里插入图片描述
雷哥思路
时序理解
翻看文档04-CGB-DB-LOG-V1.02
原型设计说明

为什么要传参数吗
输入名字根据用户名去查询查看日志信息

基于名字基于分页去查询

下一页也是一样
在这里插入图片描述

不是从当前页面获取的话最好用long

然后自己的
在这里插入图片描述

说明：
1)当DAO中方法参数多余一个时尽量使用@Param注解进行修饰并指定名字，然后在Mapper文件中便可以通过类似#{username}方式进行获取，否则只能通过#{arg0}，#{arg1}或者#{param1}，#{param2}等方式进行获取。
2)当DAO方法中的参数应用在动态SQL中时无论多少个参数，尽量使用@Param注解进行修饰并定义。

mapper层

动态sql
在这里插入图片描述
要的是值而不是表达式模糊查询

where提取出来
下面目的根据用户名查询对应信息

在这里插入图片描述
发现mybatis的共性代码
where 共性提取

注释对应目的
雷哥建议:先把代码全部看完再模仿着写

看看能取到数据吗
测试
startIndex 不仅可以从数字id开始还可以从地点开始

雷哥处报语法错误
插入的小点
在这里插入图片描述
继续续上上上图
修正
limit得放在最后
如果语法忘了
可用 mysql查询 ?select 最强大的语法

自己复述一次 pojo dao mapper 和 test
出现绑定异常

检查就是yml是最主要的错误
晚上:test那边简单得(文档有其中一个foreach答案)
Xddfathe r 11:12:22
list.forEach(item->System.out.println(item));//->为jdk8中的箭头符号

Xddfathe r 11:12:33
自己写一个简单循环和foreach循环

继续
1.数据库对不上
在这里插入图片描述
Xddfathe r 11:13:56
还有就是文件夹名字对不上

Xddfathe r 11:14:11
错误优先级文件夹名后就是url地址

还是绑定异常错误在这里插入图片描述
day04归纳有
再次对应检查
对应检查

最终问题已找到就是放错位置

test效果(正确)

现在开始写业务逻辑层

service层

直接封装日志层返回的信息
在这里插入图片描述

<value,object>类型等于一种规范一种约束比如<Long,String> 其余的实现类也必须要相同

Xddfathe r 11:46:47
和文档上不一致

Xddfathe r 11:46:54
按文档就行

Xddfathe r 11:46:57
不用long

在这里插入图片描述

@param 注解是以前版本不包含的现在直接底层就有不需要用到注解调用

下午
在这里插入图片描述
后面对业务做具体的实现
录像回看14.07之前的

不等于0继续往下走

在这里插入图片描述

在这里插入图片描述
使出现的异常更有义务含义
自定义异常要具备更好业务含义

在这里插入图片描述

在这里插入图片描述

pageObject

构建serviceTest测试

"xiaoli"是错误的用户名

正确
在这里插入图片描述

在这里插入图片描述

面向对象——三层架构（表现层、业务层、持久层）
① 持久层：采用DAO模式，建立实体类和数据库表映射（ORM映射）。也就是哪个类对应哪个表，哪个属性对应哪个列。持久层

               的目的就是，完成对象数据和关系数据的转换。

② 业务层：采用事务脚本模式。将一个业务中所有的操作封装成一个方法，同时保证方法中所有的数据库更新操作，即保证同时成

               功或同时失败。避免部分成功部分失败引起的数据混乱操作。

③ 表现层：采用MVC模式。

               M称为模型，也就是实体类。用于数据的封装和数据的传输。

               V为视图，也就是GUI组件，用于数据的展示。

               C为控制，也就是事件，用于流程的控制

 

设计原则：

           业务层接口的设计原则：一个实体类一个接口，一次提交一个业务方法。业务方法的参数来自表现层。

           持久层接口的设计原则：一个实体类一个接口，一次数据库操作一个持久方法。

controller
交给spring去管理
在这里插入图片描述

json串
在这里插入图片描述

没有状态不知道是不是正常状态
输入负值
因为没有做对应跳转页面
http://localhost:8090/log/doFindPageObjects/?pageCurrent=-1

跨端 json串
严格按照名字去定义

下一步对异常信息做处理

在这里插入图片描述

controller控制层
业务层给控制层的数据或者控制层自己封装的数据

在这里插入图片描述

在这里插入图片描述

目的基于用户名(条件)查询当前页的用户行为日志信息

重新讲一遍

业务层是service层

抽取异常代码
springmvc中定义了些异常处理的方法

可以在controller内部定义异常console控制台显示
在这里插入图片描述
类中是否有异常处理方法而不是有没有异常

springmvc 前端控制器帮我们调用
调用全局异常这个方法(加断点有空学)

看异常处理的过程
先找局部的处理没有就找上头

全局
html 客户端有页面没数据在这里插入图片描述

服务端返回的

建立思路看文档