Spring 的 5.0初始 jdbc 來呈現 耦合的問題
Spring 大概起始於 2002 年的 interface21 的： 這是 Spring前身的一個主要的標誌 9是j2EE 開發的， 拋棄了 不使用EJB
這次介紹的是Spring5.0 與 2017 年09月 釋出的 通用 (GA)
Spring 都有那些優勢#####
幾乎所有的框架 的趨勢與共性 ：
解耦 與 簡化開發的
Spring通過 IOC 容器 來實現的 IOC 裡 將 Object 之間的 依賴關係 分別讓Spring來管理 ，削減 了的硬編碼的 單例模式 與 檔案解析 。。。。。這些的 使我們 可以更多的專注於程式設計的應用
AOP 的面向切片
的 的 就像 生物實驗 的 裡的切片研究一樣 ’
讓oop 的實現功能 也已他送應付
宣告 事務：靈活 提高開發的效率
方便程式的測試： 無需 容器的依賴
方便整合，整合了各種 框架的
Struts Hibemate Mybatise ， Hessian Quartz 等）的直接支援
降低 JavaEE API 的使用難度
Spring 對 JavaEE API（如 JDBC、JavaMail、遠端呼叫等）進行了薄薄的封裝層，使這些 API 的
使用難度大為降低。
Java 原始碼是經典學習範例
Spring 的原始碼：的學習的是我們最 應該的 修煉的 有很多 的 Java 設計模式靈活運用以
及對 Java 技術的高深造詣。它的原始碼 是 Java 技術的最佳實踐的範例
我要分享的是 與實現的## 標題
1：基於xml 的IOC 配置
2：基於註解annotation
言簡意賅 之後 開始我的見習 得Spring
方便解耦 與簡化開發 2：
工廠模式 ： 工廠是 幹什麼的
JavaMail ： 我們以前的時候 10行到20行 的程式碼 -----只用了Spring 只有4，5行
Spring 原始碼：剛開始還是建議少看這些 ----會很朦的》
在Spring 的體系結構#######
Spring體系結構-----------------------》
我們在官方的FRAMEWORK 框架骨架 doewnload裡就能 先找到 Spring的座標 在匯入
今天的原始碼裡 就有
libs 解壓的時候 會有 framework runtime
官方 的 這張圖的結構
底層上==
Core container： 核心容器（IOC）— 是 Spring任何 執行 基礎 （的支援）
Beans Core：核心 Context： 上下文 SpEL：斯巴沙星
—接著就是 AOP 相關的內容：有4個 包括Messaging
—左上方的==Date Access/Integration：數## 標題據存取整合
==持久層
JDBC： ORM：相關 Transaction：事務 oxm jms — （網上查詢）
—右上方的
servlet， web 熟悉吧 WebSocket Portlet — （網上查詢）
後面的 springMVC , stusts
最底層的就是： 單元測試 Test
我們先要了解最重要的核心容器 IOC 概念–程式的耦合 ----解耦
下面 引用 一下介紹耦合的 分類
它有如下分類：
（1）內容耦合。當一個模組直接修改或操作另一個模組的資料時，或一個模組不通過正常入口而轉入另
一個模組時，這樣的耦合被稱為內容耦合。內容耦合是最高程度的耦合，應該避免使用之。
（2）公共耦合。兩個或兩個以上的模組共同引用一個全域性資料項，這種耦合被稱為公共耦合。在具有大
量公共耦合的結構中，確定究竟是哪個模組給全域性變數賦了一個特定的值是十分困難的。
（3） 外部耦合 。一組模組都訪問同一全域性簡單變數而不是同一全域性資料結構，而且不是通過引數表傳
遞該全域性變數的資訊，則稱之為外部耦合。
（4） 控制耦合 。一個模組通過介面向另一個模組傳遞一個控制訊號，接受訊號的模組根據訊號值而進
行適當的動作，這種耦合被稱為控制耦合。
（5）標記耦合 。若一個模組 A 通過介面向兩個模組 B 和 C 傳遞一個公共引數，那麼稱模組 B 和 C 之間
存在一個標記耦合。
（6） 資料耦合。模組之間通過引數來傳遞資料，那麼被稱為資料耦合。資料耦合是最低的一種耦合形
式，系統中一般都存在這種型別的耦合，因為為了完成一些有意義的功能，往往需要將某些模組的輸出資料作為另
一些模組的輸入資料。
（7） 非直接耦合 。兩個模組之間沒有直接關係，它們之間的聯絡完全是通過主模組的控制和呼叫來實
現的。
總結：
耦合是影響軟體複雜程度和設計質量的一個重要因素，在設計上我們應採用以下原則：如果模組間必須
存在耦合，就儘量使用資料耦合，少用控制耦合，限制公共耦合的範圍，儘量避免使用內容耦合。
內聚與耦合
內聚標誌一個模組內各個元素彼此結合的緊密程度，它是資訊隱蔽和區域性化概念的自然擴充套件。內聚是從
功能角度來度量模組內的聯絡，一個好的內聚模組應當恰好做一件事。它描述的是模組內的功能聯絡。耦合是軟體
結構中各模組之間相互連線的一種度量，耦合強弱取決於模組間介面的複雜程度、進入或訪問一個模組的點以及通
過介面的資料。 程式講究的是低耦合，高內聚。就是同一個模組內的各個元素之間要高度緊密，但是各個模組之
間的相互依存度卻要不那麼緊密。
內聚和耦合是密切相關的，同其他模組存在高耦合的模組意味著低內聚，而高內聚的模組意味著該模組同其他
模組之間是低耦合。在進行軟體設計時，應力爭做到高內聚，低耦合。
。
在開發中，有些依賴關係是必須的，有些依賴關係可以通過優化程式碼來解除的。下面的示例
-------這是一個賬戶 的Account
public class AccountServiceImpl implements IAccountService {
private IAccountDao accountDao = new AccountDaoImpl();
}
上面的程式碼表示：
業務層呼叫持久層，並且此時業務層在依賴持久層的介面和實現類。如果此時沒有持久層實現類，編譯
將不能通過。這種編譯期依賴關係，應該在我們開發中杜絕。我們需要優化程式碼解決
—通過 JDBC 的 的程式碼 。。。
再比如：早期我們的 JDBC 操作，註冊驅動時，我們為什麼不使用 DriverManager 的 register 方法lass.forName 的方式？public class JdbcDemo1{
public static void main(String[] args) throws Exception {
//1.註冊驅動
//DriverManager.registerDriver(new com.mysql.jdbc.Driver());
Class.forName(“com.mysql.jdbc.Driver”);
//2.獲取連線
//3.獲取預處理 sql 語句物件
//4.獲取結果集
//5.遍歷結果集
}
}
原因就是：
我們的類依賴了資料庫的具體驅動類（MySQL），如果這時候更換了資料庫品牌（比如 Oracle），需要
修改原始碼來重新資料庫驅動。這顯然不是我們想要的
}
解決程式耦合的思路
當是我們講解 jdbc 時，是通過反射來註冊驅動的，程式碼如下：
Class.forName(“com.mysql.jdbc.Driver”);//此處只是一個字串
此時的好處是，我們的類中不再依賴具體的驅動類，此時就算刪除 mysql 的驅動 jar 包，依然可以編譯（運
行就不要想了，沒有驅動不可能執行成功的）。
同時，也產生了一個新的問題，mysql 驅動的全限定類名字串是在 java 類中寫死的，一旦要改還是要修改
原始碼。
解決這個問題也很簡單，使用配置檔案配置
工廠模式解耦
在實際開發中我們可以把三層的物件都使用配置檔案配置起來，當啟動伺服器應用載入的時候，讓一個類中的
方法通過讀取配置檔案，把這些物件創建出來並存起來。在接下來的使用的時候，直接拿過來用就好了。
那麼，這個讀取配置檔案，建立和獲取三層物件的類就是工廠
我的分析-------------Spring將會解決的問題—編寫JDBC 的演示程式的耦合-------》
演示程式的耦合；
引出的 現有程式碼問題： ------ 注意的是 類的依賴
一個案例 ：
JDBCDemo01-----》耦合問題的
–用連線 資料庫 -------》編譯時期 的依賴 即耦合
package com.fhw.jdbc;
import java.sql.*;
/**
-
程式的耦合
-
資料庫 裡準備 庫，表 ：SQL語句
-
減少依賴的方式 ： 削減/減少
-
/DriverManager.registerDriver(new com.mysql.jdbc.Driver()); 依賴具體的類/
//使用反射： 解耦 新的問題 ： 字串 在類還是寫死了 如換其他的資料庫// Class.forName("com.mysql.jdbc.Driver");
public class JdbcDemo01 {
public static void main(String[] args) throws Exception {
// 註冊驅動
/DriverManager.registerDriver(new com.mysql.jdbc.Driver()); 依賴具體的類/
//使用反射： 解耦 新的問題 ： 字串 在類還是寫死了 如換其他的資料庫
Class.forName("com.mysql.jdbc.Driver");//字串的方式 加上依賴：maven 的mysql 的依賴 解決了類 的依賴
//獲取連線
Connection con= DriverManager.getConnection("jdbc:mysql://localhost:3306/ffff","root","root");
//獲取操作資料庫的預處理物件
PreparedStatement pstm=con.prepareStatement("select *from account");
//執行資料庫
ResultSet rs = pstm.executeQuery();
//遍歷擊結果
while (rs.next()){// 從表頭 的 到 表的內容 next（）
System.out.println(rs.getString("name"));;
}
//釋放資源
pstm.close();
con.close();
}
}
maven 的pom.xml 檔案
<?xml version="1.0" encoding="UTF-8"?>
4.0.0
<groupId>com.fhw</groupId>
<artifactId>fhw01_01JDBC</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version> 5.1.6</version>
</dependency>
</dependencies>
編譯期依賴---------------------》
我們解決： 經常要用的 放在在我們的pom依賴
依賴是 需要降低 就能 增加獨立自主—》具體的是： 編譯時不依賴 執行時再依賴
曾經程式碼中的問題分析-----------------------------》
模擬一下：
建立新的module：-----》 介面
這些都是 之前做過的 實現類 多型new的現象 就是要避免 和 解耦的 可以用的 優化
業務層 在呼叫 持久層 也在 表現層 到 持久層 都會共有的 問題s
我們maven的座標啊 地方就是 jar 的方式 （沒有座標的）沒有瀏覽器與web
在模擬一個表現層 （實際裡這裡就是一個 servlet）
我們呈現 了好多的依賴 這就是我們要解決的！
之前的程式碼L我們----綜合案例–》regist-- 我們通過 傳送郵件 那麼 要換的是 簡訊呢？
我們要改的是 ===》二期開發（儘量不修改）
我們再 寫一個UserService 實現類
javaBean:
實體類僅僅 是指
解耦：
反射 + 配置檔案 + Factory工廠模式
其實 我們的之前用過的 反射 + 配置檔案 +工具類 ，工具類就類似 工廠模式
-------- 解決 降低的依賴-- 編寫工廠類和配置檔案 ---------==================》
Bean.prorperties:
在static程式碼塊 裡 定義了 讀取 配置檔案 的資料-----》立即載入
現在解耦了嗎： Service裡依賴 具體的實現類 模擬的servlet 依賴於 Service
在改造： 消減new 就是減依賴