第六次的服务端课程：JDBC，数据源配置
文章目录
- 1：回顾
- 2：JDBC
- 1：基本使用
- 3：spittle
- 1：业务和数据的解耦
- 2：异常体系
- 3：模板方法
- 4：配置数据源的方式
- 1：连接
- 2：测试
- 3：namedtemplated
1：回顾
- spring security
- web层面的 我们可以实现类，继承一个ASWI
- 开启一个servlet，拦截所有的请求，交给filter，做一系列的串行的执
- 2：具体的url，开启一些列的权限
- 配置登录的页面
- http basic 认证
- 启动remember me 功能
- 放置跨站伪造 CSRF
- 3：配置用户的数据
- 内存，数据库表configure（）
- 针对某一些url，是不是要开启安全通道
- SSL的安全通道
- secured(“权限”，“role__andmin”)
- admin这个角色，它具备的这个权限
- JSR-250
- 这个是一个规范，脱离spring
- 表达式驱动的注解
- 在方法之前，看是否能调用这个方法
- 简述spring security提供的
2：JDBC
1：基本使用
- getConnection
- statement中的信息都是以问号的方式给出来的
- 数据库中有很多的异常，网络，语法
- SQLException 这是一个底层的异常
- 特点
- 复杂，啰嗦
- 真正的代码只有insert插入，这一行
- 还要抓异常
3：spittle
- 右边是一个人，左边是一个表
- 一个人有多个博客
1：业务和数据的解耦
- 便于测试，便于测试接口层
- 数据库自身和数据库的访问方式
- JDBC
- hibernate
2：异常体系
-
下面的三种异常都是 runtimeException异常
-
数据库的异常，一般不能够再回复，必须抛出
-
SQLException
- 发生异常的时候，很难恢复
- 难以确定异常的体系，难以定位
-
Hibernate异常
- 定义了许多具体的异常，方便定位问题
- 对业务代码的侵入性
- hibernate自己定义的的异常，就会向上抛异常
- 可能在业务对象上捕获异常，就要处理异常
- 下次换成mybatis，业务对象的代码又要改变
-
DataAccessException：平台无关的持久化异常
- 具体异常，方便定位问题
- 隔离具体数据库平台
-
异常的区别
- runtimeException
- 你不需要try
- Exception
- 你一定要 try
- runtimeException
3：模板方法
- template method
- 一共都是四个步骤，第一步，第二步，第三步，第四步
- 但是不同的场景，第二部是有区别的
- ‘
4：配置数据源的方式
1：连接
- 根据JNDI查找的数据源
- tomcat
- 告诉tomcat，我的数据库在哪里，账号密码
- dataSource，这个配置是通过web容器来配置的
- 连接池的数据源
- javax.sql.DataSource
- 连接池里面放的是 一个个的 Connection
- 数据库都是远程的，连接完了，就释放掉了，就很浪费
- 初始化五个放在那里
- 最多可以创建十个
- 使用阿里的连接池
- spring的池子
- 本质上不是池子，来了才连接
- embeddedDataSource
- 嵌入到web空间中的，基于内存的数据库
- 把数据放在内存，进行管理
- 多个数据源
- 开发和测试
- 通过JDBC驱动程序定义的数据源
- JDBCtemplate 获取到
- 做sql的查询，那么我们就调用query
2：测试
- transcational
- 测试完之后，会给你进行回滚
- @Rollback
3：namedtemplated
JAVA -D
1：定义datasource
2：创建jdbctemplate // 之后ORM JPA 又是另外的一种方式，更加的简单吗，你只需要定义一个接口，接口的实现，spring来帮你做
-
测试代码不变
-
dao层的结构不变
-
层和层之间也是通过接口来依赖
-
配置嵌入式的数据源
-
tomcat
- 告诉tomcat，我的数据库在哪里，账号密码
作业：把第一节课的数据和业务放一起，进行优化
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！