概念回顧
回顧下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簡介（九）