第六次的服务端课程：JDBC，数据源配置
生活随笔
收集整理的這篇文章主要介紹了
第六次的服务端课程：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，我的數據庫在哪里，賬號密碼
作業：把第一節課的數據和業務放一起，進行優化
總結
以上是生活随笔為你收集整理的第六次的服务端课程：JDBC，数据源配置的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： jenkins active exite
- 下一篇： java 8