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簡介（九）

原文出處：https://www.cnblogs.com/noteless/p/10319299.html