JDBC與ORM發展與聯絡 JDBC簡介（九）
概念回顧
回顧下JDBC的概念：
JDBC（Java Data Base Connectivity,java資料庫連線）是一種用於執行SQL語句的Java API，可以為多種關係資料庫提供統一訪問，它由一組用Java語言編寫的類和介面組成。
JDBC提供了一種基準，據此可以構建更高階的工具和介面，使資料庫開發人員能夠編寫資料庫應用程式。
JDBC是Java資料庫連線技術，所以，他必然根植於Java語言，使用JDBC離不開Java開發環境，是Java語言對於資料庫連線的技術實現。
JDBC作為一種協議的體現，在Java程式碼中就是一系列的介面與實現的約定。
資料庫驅動廠商以及應用程式開發者基於這一協議進行對接，從而解耦，從而可以相互分離的獨立發展。
既然最終體現形式為一組API這組API到底做了什麼？
想要了解JDBC到底做了什麼，在windows平臺的話，可以直接開啟命令視窗
根據使用者名稱密碼進行連線，然後傳送語句，然後檢視結果
JDBC是Java資料庫連線，仍舊是在做”連線資料庫“這件事情本身，哪怕變出花來，他的根本仍舊是連線資料庫
資料庫就是那個資料庫，他一直在那裡，資料庫有他們固有的操作流程步驟以及SQL執行規範
當你用命令視窗連線資料庫，傳送SQL語句時，你是在操作資料庫
使用JDBC只是換了一種方式，不再是手動了，而是藉助於Java程式碼，然後依賴於底層的資料庫驅動，去操作資料庫
簡言之，你本來是在命令窗口裡面，輸入一行SQL之後敲回車
現在變成了藉助於Java程式碼，通過幾個物件相互配合進而傳送SQL
做的所有事情都沒有任何變化，查詢還是那個查詢，更新還是那個更新，變得只是形式
你以為開個法拉利去車站接人和騎電動車去接人有本質區別麼？
你要做的還是去車站接人，你要接的人還是那個人，但是形式變了，停車位置變了，時間變了，連旁邊的妹子看你得眼光可能也變了，但是，但是，你的事兒還是那個事兒，如果接不到人，一切還不是扯淡？
所以說一個數據庫客戶端一般可以提供給我們那些服務，JDBC就能夠提供給我們那些服務
不過，對於客戶端來說，結果直接就可以呈現出來了，但是對於Java程式碼---方法的呼叫，需要處理更多的細節，哪些是輸出，哪些是輸入，引數的傳遞
所以JDBC沒有看起來這麼簡單
JDBC作為資料庫連線的中間層，將應用程式與資料庫連線進行解耦，給開發者提供了極大地方便，從此以後，再也不需要面向資料庫驅動進行程式設計了
只需要面向JDBC進行程式設計即可，所以JDBC的出現，對於Java連線資料庫實現了大一統的局面，解放了生產力
但是，你既然作為中間層，將兩者進行解耦，你就要負責對接，否則就真的徹底斷開了，就不叫做解耦了。。。
這其中最重要的一點就是結果集的返回
對於類似命令列或者Navicat的客戶端，是直觀的呈現，眼睛來識別，而對於介面呼叫，則是API各個方法中的資料的對接，結果集的解析
JDBC是對資料庫操作的Java描述，所以對於比如查詢來說，結果集的邏輯呈現也是下圖類似式樣
JDBC對於結果集的處理核心就是將這樣子的資料返回給應用程式，直觀看起來很簡單的行列，對映到欄位中就涉及到很複雜的轉換了
總共有多少行記錄？又有多少列？有哪些欄位是要處理的？欄位順序是什麼？欄位型別是什麼？SQL型別與Java型別又是如何對映？有些欄位的精度又是什麼？
某列的值應該跟哪一個實體中的欄位進行對照？等等這些都是結果集要處理的，所以說JDBC的確又很複雜
不得不面對的問題
冗餘程式碼
藉助於JDBC程式設計，有很多模組化的程式碼，在第一個JDBC示例中，所有的步驟都是需要按部就班完成的
而這些步驟很顯然，有些是結構化的模式化的，比如連線資料庫，關閉連線，異常處理，這些其實對於應用開發者其實並不想處理，但是卻不得不處理
簡言之，JDBC功能足夠，但是便捷性欠缺，結構化本身沒錯，結構化模式化流程化才能成為標準，但是必然會產生冗餘步驟， 如何靈活是一個問題
物件對映
目前儲存資料最常用最流行的工具是關係型資料庫，我們通過JDBC藉助於SQL語句操作資料庫，但是Java是面向物件的程式語言，所有的操作都是物件
在使用JDBC進行操作時，面向物件的概念卻被弱化了
比如下面的這一段程式碼，對於引數的設定，是按照屬性欄位的索引，你看不到物件的影子
你可能希望有這麼一個學生Student類
這個類有幾個屬性：id、姓名、年齡、性別
當需要執行下面的插入行為時，可以直接將Student的物件例項直接傳遞進去即可，而不是這樣按照索引去設定。
結果集的取回也是類似的
當你想要查詢一個列表時，你不得不如下這般處理
你是不是會想，我有一個Student類了，為什麼不能直接給我返回一個List<Student> ？那樣不是很方便麼？
所以看得出來，Java作為純粹的面向物件程式語言，一切皆是物件，但是目前常用的資料庫卻是關係型資料庫
關係模型就像一張二維表格，因而一個關係型資料庫就是由二維表及其之間的聯絡組成的一個數據組織，這並不是物件型的
JDBC的操作方式是也不是面向物件的，整個過程面向物件程式設計的思維觀念很大程度上被遏制了
所以，儘管JDBC將應用程式與資料庫驅動進行解耦，應用程式開發者面向JDBC進行程式設計，而不需要面向資料庫進行程式設計
但是誰也沒辦法否認Java是純粹的面向物件，所以在物件與關係型資料庫的欄位之間，又缺少了一層，這層用於將欄位與物件進行對映對照
沒有這層功能，只能是應用程式開發者藉助於JDBC自己手動的將欄位組裝成物件，很繁瑣，而且，不成規範，就如同沒有JDBC之前開發資料庫操作的程式那樣，需要自己實現。
簡言之，關係型資料庫不是面向物件的，而JAVA卻是純粹的面向物件的語言，這勢必不能很流暢的合作，JDBC物件的對映全靠自己
ORM
鑑於以上提出來的問題，在使用Java開發時，我們希望真正的建立一個物件型資料庫，或者說至少使用起來看起來像一個物件型資料庫
但是，目前常用的資料庫又的確是關係型資料庫，這一點短期內又無法改變
所以出現了ORM，物件關係對映（Object Relational Mapping，簡稱ORM，或O/RM，或O/R mapping）
面向物件是從軟體工程基本原則（如耦合、聚合、封裝）的基礎上發展起來的，而關係資料庫則是從數學理論發展而來的，兩套理論存在顯著的區別。
而面向物件的程式設計思想是軟體開發的一大趨勢，而關係資料庫也是目前的必然存在，兩種理論的差別的不匹配，造就了ORM，亂世出英雄。
ORM到底做什麼？
JDBC將應用程式開發者與底層資料庫驅動程式進行解耦，作為中間層承上啟下
而ORM是插入在應用程式與JDBCAPI之間的一箇中間層，JDBC並不能很好地支援面向物件的程式設計
ORM解決了這個問題，通過JDBC將欄位高效的與物件進行對映
應用程式開發人員不再需要直接與JDBC API進行打交道了，可以使用更加便利的ORM工具，提高開發效率
所以ORM是幹什麼的？
ORM用於完成Java物件與關係型資料庫的對映，是JDBC的一層封裝，提高了易用性。
簡言之，ORM工具就是JDBC的封裝，簡化了JDBC的使用，完成關係型資料庫中資料與Java物件的對映。
ORM工具框架最大的核心就是封裝了JDBC的互動，你不在需要處理結果集中的欄位或者行或者列
藉助於ORM可以快速進行開發，而無需關注JDBC互動細節
但是既然是JDBC的封裝，多一層封裝，就勢必會帶來效能的開銷，這是無法迴避的事實，不過現在技術不斷髮展，效能開銷越來越小。
從上面的解釋看，好似有些狹義，會認為ORM框架僅僅完成物件的對映，其實並不然，ORM最原始的是一個概念，所有的ORM產品是基於ORM思想的實現實體
他們往往都附加了更多的功能，比如很多ORM框架也叫做持久化ORM框架
什麼意思呢?
持久化簡單理解就是脫離記憶體可以獨立儲存，儲存到資料庫，儲存到檔案等等形式，都是持久化
“持久化ORM框架”中的持久化一般是指儲存到資料庫，所以說如果一個ORM提供了CRUD操作API，應用程式可以藉助於ORM完成資料持久化的操作，這就算是一個持久化ORM框架
就如同很多DataSource的實現中添加了很多功能，有些就直接被叫做資料庫連線池
所以說具體怎麼講，都是字面的含義，真正需要做的是理解ORM思想的含義：
完成物件與關係型資料庫的對映，封裝底層與資料庫的互動，並且很多都提供了強大的附加功能，比如持久化
現在的ORM基本上都是包括對持久類物件進行CRUD操作的API
對於Java來說，常用的有Hibernate和Mybatis（iBatis）還有Spring JDBC等，在ORM核心思想的基礎上週邊又做了很多事情
所以說基本上很少有人直接使用原生的JDBC，可能有的公司中不會使用這些框架，因為畢竟框架的引入會犧牲效能
而且框架是作為JDBC的封裝，就好比一個工具類，而且是別人封裝的工具類，終歸有些地方可能有的人用的不順手，或者說不適合有些場景，大公司有些會自己研發一套自己需要的類ORM工具，自己使用
ORM框架各有千秋利弊，你可以不用各種已成的框架，但是，沒有任何人可以否定ORM背後的思想， ORM會一定程度上降低效能但是藉助於程式碼生成工具等可以極大地提高開發效率
而且，ORM工具有極強的可維護性，雖然會降低效能，但是更多的時候可能是程式碼不夠完美，演算法不夠高明，邏輯不夠清晰，所以負責任的說ORM在很多場景都是很好的一種選擇。
原文地址: JDBC與ORM發展與聯絡 JDBC簡介（九）