Java專家之路（二）---資料訪問和資料持久化框架的總結
Java資料訪問和持久化（SQL）
方案一：JDBC
什麼是JDBC?
Java語言訪問資料庫的一種規範,是一套API。JDBC (Java Database Connectivity) API，即Java資料庫程式設計介面，是一組標準的Java語言中的介面和類，使用這些介面和類，Java客戶端程式可以訪問各種不同型別的資料庫。
JDBC規範採用介面和實現分離的思想設計了Java資料庫程式設計的框架。介面包含在java.sql及javax.sql包中，其中java.sql屬於JavaSE，javax.sql屬於JavaEE。
為了使客戶端程式獨立於特定的資料庫驅動程式，JDBC規範建議開發者使用基於介面的程式設計方式，即儘量使應用僅依賴java.sql及javax.sql中的介面和類。
架構圖：
JDBC規範下載連結
JAVA使用JDBC訪問資料庫的步驟:
1.得到資料庫驅動程式
2.建立資料庫連線
3.執行SQL語句
4.得到結果集
5.對結果集做相應的處理(增,刪,改,查)
6.關閉資源:這裡釋放的是DB中的資源
例項練習
方案二：JdbcTemplate
jdbcTemplate是什麼？
點選檢視——》Spring官方參考：
如果是傳統的JDBC程式碼，就連簡單的select語句也需要冗長的出錯處理，並且每個函式都不斷地重複同樣的程式碼。
JdbcTemplate正是為了減少上述繁瑣的程式碼而設計出來的。它是對JDBC的一種封裝，抽象我們常用的一些方法。Simple and Stupid就是它的目標。
JdbcTemplate是spring提供的替代原生JDBC的類。
應用場景？
如果選用了spring框架，而且你針對資料庫訪問也不是很複雜，那麼你選擇JdbcTemplate作為資料訪問非常合適。
JdbcTemplate的好處是：整合在spring框架中，不需要繼承額外的其他資料訪問的jar包；
JdbcTemplate的方法相對也簡單，spring已經封裝了很多具體操作。
例項操作
方案三：ORM
ORM是什麼？
ORM 是Object-Relation-Mapping，即物件關係影射技術，是物件持久化的核心
詳情請戳——>百科介紹
為什麼需要ORM？
主要是解決jdbc的各種問題
ORM是對JDBC的封裝，從而解決了JDBC的各種存在問題：
- a) 繁瑣的程式碼問題
用JDBC的API程式設計訪問資料庫，程式碼量較大，特別是訪問欄位較多的表的時候，程式碼顯得繁瑣、累贅，容易出錯。
例如：
PreparedStatement pstmt=con.prepareStatment("insert into account value(?,?,?,?,?,?,?,?,?)");ORM則建立了Java物件與資料庫物件之間的影射關係，程式設計師不需要編寫複雜的SQL語句，直接操作Java物件即可，從而大大降低了程式碼量，也使程式設計師更加專注於業務邏輯的實現。
- b) 資料庫物件連線問題
關係資料物件之間，存在各種關係，包括1對1、1對多、多對1、多對多、級聯等。在資料庫物件更新的時候，採用JDBC程式設計，必須十分小心處理這些關係，以保證維持這些關係不會出現錯誤，而這個過程是一個很費時費力的過程。
ORM建立Java物件與資料庫物件關係影射的同時，也自動根據資料庫物件之間的關係建立Java物件的關係，並且提供了維持這些關係完整、有效的機制。
- c) 系統架構問題
JDBC屬於資料訪問層，但是使用JDBC程式設計時，必須知道後臺是用什麼資料庫、有哪些表、各個表有有哪些欄位、各個欄位的型別是什麼、表與表之間什麼關係、建立了什麼索引等等與後臺資料庫相關的詳細資訊。
使用ORM技術，可以將資料庫層完全隱蔽，呈獻給程式設計師的只有Java的物件，程式設計師只需要根據業務邏輯的需要呼叫Java物件的Getter和 Setter方法，即可實現對後臺資料庫的操作，程式設計師不必知道後臺採用什麼資料庫、有哪些表、有什麼欄位、表與表之間有什麼關係。
d) 效能問題
採用JDBC程式設計，在很多時候存在效率低下的問題。
pstmt =conn.prepareStatement(“insert into user_info values(?,?)”);
for (int i=0; i<1000; i++) {
pstmt.setInt(1,i);
pstmt.setString(2,”User”+i.toString());
pstmt.executeUpdate();
}
以上程式將向後臺數據庫傳送1000次SQL語句執行請求，執行效率較低。
採用ORM技術，ORM框架將根據具體資料庫操作需要，會自動延遲向後臺數據庫傳送SQL請求，ORM也可以根據實際情況，將資料庫訪問操作合成，儘量減少不必要的資料庫操作請求。
ORM的優勢
首先，讓我們來做下比較，在同等條件同等資料量的情況，不使用ORM與使用ORM相比，顯然不使用ORM執行時間會快那麼一點點，但這點你很快就覺得沒什麼可值得驕傲的了：比如你在某次頁面資料互動中，因使用ORM執行時間用了200ms，而沒有使用ORM執行時間只須要190ms，提高了10ms啊！！！如果你做的是底層，提高的是CPU運算速度或者是I/O的速度，確實不賴。而這裡是資訊系統，這些在使用者面前根本就感覺不到，即使你用了210ms、220ms使用者也不關心這些，然而為了能夠提高這些微不足道的x毫秒，你卻要寫大量重複的程式碼，不停的Ctrl+C/Ctrl+V，最後程式碼日積月累，你的程式碼行確實增加了，而且很快，日復一日，年復一年…恭喜，你終於成為一個程式碼量超過x萬行的偉大的程式碼民工(不享受農民工待遇的“高階高素質”IT民工)！其實通過Cache的實現，能夠實現對效能的調優。
其次，從專案週期和開發進度上來說，ORM無疑提供了最佳方案。物件對映可以使業務物件與資料庫分離，使資料庫層透明，開發人員真正的面向物件。ORM通過對開發人員隱藏SQL細節可以大大的提高生產力。沒有哪個專案不計成本，無限制拖延下去的，多數是盡少投入儘快完成，還要易維護。使用ORM可以大大降低學習和開發成本。實際開發中，真正對客戶有價值的是其獨特的業務功能，而不應該把大量時間花費在寫資料訪問、增刪改查(CRUD)方法、後期的Bug查詢和維護上。在使用ORM後，ORM框架已經把資料庫變成了我們所熟悉的實體物件，我們只需瞭解面向物件開發就可以實現資料庫應用程式的開發，不需要浪費時間在SQL上。同時也可減少程式碼量，減少資料層出錯機會。
再次，從職業生涯規劃和人員能力提升方面，ORM因為節省大量的開發時間，無疑可以讓開發人員有機會去做更有意義的事情，涉獵更多的知識。如果某人始終從事的都是這些模式重複的程式碼開發，頂多就是個熟練工。
最後，從根本上講，當前資訊系統開發基本上都是基於面向物件和關係資料庫的，而面向物件是從軟體工程基本原則(如耦合、聚合、封裝、繼承、多型)，而關係資料庫則是從數學理論（如關係模型、關係代數、關係運算、函式依賴）發展而來的，兩套理論存在顯著的區別。ORM就是為解決這個不匹配的現象而產生的。所以從某種意義講，在ORM還未完全普遍存在的情況下，這種CRUD，也為想進入IT行業的一些青年提供了入門的機會；如果某天ORM像SQL語句或程式的順序、分支、迴圈一樣普遍，這樣的IT從業者，何去何從還另當別論，然而國人大多數開發人員都是做CRUD的。
ORM帶來了什麼樣的問題？
ORM是否非得使用？
- 如果你不處理物件，使用ORM就沒什麼意義了。
- 如果您的關係表/列與物件/屬性對映1：1，則使用ORM沒有太多的意義。
- 如果您的物件與其他物件沒有任何1：1，1：m或m：n關係，則使用ORM並不重要。
- 如果您有複雜的手動調優SQL，則使用ORM沒有太多意義。
- 如果您決定將資料庫作為其介面儲存過程，則使用ORM沒有太多意義。
- 如果您有一個不能重構的複雜的舊模式，則使用ORM沒有太多的意義。
所以這裡是相反的：如果你有一個堅實的物件模型，物件之間的關係是1：1，1：m和m：n，沒有儲存過程，就像ORM解決方案將給出的動態SQL 你一定要用ORM。
ORM的實現原理、思路？
有哪些ORM方案可供選擇？
Hibernate
Hibernate的前世今生
2001年，澳大利亞墨爾本一位名為Gavin King的27歲的程式設計師，在這一年的11月，釋出了Hibernate的第一個版本。
2002年，已經有人開始關注和使用Hibernate了
2003年9月，Hibernate開發團隊進入JBoss公司，開始全職開發Hibernate，從這個時候開始Hibernate得到了突飛猛進的普及和發展。
2004年，整個Java社群開始從實體bean向Hibernate轉移，特別是在Rod Johnson的著作《Expert One-on-One J2EE Development without EJB》出版後，由於這本書以紮實的理論、充分的論據和詳實的論述否定了EJB，提出了輕量級敏捷開發理念之後，以Hibernate和Spring為代表的輕量級開源框架開始成為Java世界的主流和事實標準。在2004年Sun領導的J2EE5.0標準制定當中的持久化框架標準正式以Hibernate為藍本
2006年，J2EE5.0標準正式釋出以後，持久化框架標準Java Persistent API（簡稱JPA）基本上是參考Hibernate實現的，而Hibernate在3.2版本開始，已經完全相容JPA標準
Hibernate的實現原理
Hibernate的應用場景？
快速迭代 適合 使用面向物件的 持久層框架。在開發過程中 物件的變更非常頻繁。
這種 持久層框架 適合 快速 重構 ，提高開發效率。
但是 這種框架 易學難精，用的不好就容易造成效能問題，用的好效能並不輸於ibatis框架。
在做效能優化方面 可藉助 快取實現。
Hibernate和ORM的關係？
Hibernate對資料庫結構提供了較為完整的封裝，Hibernate的O/R Mapping實現了POJO 和資料庫表之間的對映，以及SQL 的自動生成和執行。程式設計師往往只需定義好了POJO 到資料庫表的對映關係，即可通過Hibernate 提供的方法完成持久層操作。程式設計師甚至不需要對SQL 的熟練掌握， Hibernate/OJB 會根據制定的儲存邏輯，自動生成對應的SQL 並呼叫JDBC 介面加以執行。
小結：ORM是一種思想，Hibernate是實現了ORM思想的java持久層ORM框架。
ibatis/MyBatis——別具一格的ORM
mybatis的前世今生?
Ibatis：iBATIS一詞來源於“internet”和“abatis”的組合
在2001年，一個叫做iBATIS的專案由Clinton Begin創立。最初的重點是加密軟體解決方案的開發。第一個由iBATIS釋出的產品是Secrets，[1]與PGP類似的個人資料加密和簽名工具。祕密是完全用Java編寫的，是在開源許可下發布的。那一年，微軟發表了一篇文章[2]來證明其最近的.NET 1.0框架比Java更有生產力。為此，微軟建立了自己的Sun公司的Web版本“Pet Store”，這是Sun用來展示Java最佳實踐（Java BluePrints）的Web專案。微軟聲稱.NET比Java快十倍，四倍。
2002年，克林頓開發了一個名為JPetStore的應用程式來演示Java可能比.NET更高效，也可以實現比Microsoft實現更好的體系結構。 JPetStore 1.0產生了很大的影響[4]，克林頓使用的資料庫層次引起了社群的關注。很快，iBATIS資料庫層1.0專案就開始了，由兩個元件組成：iBATIS DAO和iBATIS SQL Maps。 iBATIS 2.0於2004年6月釋出。[5]這是一個完整的重新設計，同時保持相同的功能。克林頓向iBATIS軟體基金會捐贈了iBATIS的名字和程式碼，這個專案在ASF留了六年時間。最終iBATIS DAO被棄用，考慮到更好的DAO框架，如Spring框架。
2010年5月19日，iBATIS 3.0釋出，同時開發團隊決定繼續開發Google Code的框架[6]。在一個名為MyBatis的新專案下。
2010年6月16日，Apache宣佈iBATIS退休並搬到了Apache Attic。
MyBatis 是一款優秀的持久層框架，它支援定製化 SQL、儲存過程以及高階對映。MyBatis 避免了幾乎所有的 JDBC 程式碼和手動設定引數以及獲取結果集。MyBatis 可以使用簡單的 XML 或註解來配置和對映原生資訊，將介面和 Java 的 POJOs(Plain Old Java Objects,普通的 Java物件)對映成資料庫中的記錄。
點選連結——》官網參考：
mybatis的實現原理？
mybatis和ORM的關係？
mybatis的著力點，則在於POJO 與SQL之間的對映關係。然後通過對映配置檔案，將SQL所需的引數，以及返回的結果欄位對映到指定POJO。 相對Hibernate“O/R”而言，mybatis是一種“Sql Mapping”的ORM實現。
小結：ORM是一種思想，mybatis是這種思想下的一種實現方式。
mybatis和Hibernate的對比？
點選——》參考連結：
小結：我們的評價應該要客觀實在，兩種ORM實現框架，各有各的優勢和特點，應看具體業務需求特點來做選擇，然後根據框架的特點，並遵循各自框架的最佳實踐的原則來使用你所選擇的框架，對其進行不斷的優化。
mybatis的應用場景？
它封裝少、高效能·可優化、維護簡單等優點成為了目前java移動網際網路網站服務的首選持久層框架，它特別適合分散式和大資料網路資料庫程式設計。
系統資料處理量巨大，效能要求極為苛刻，這往往意味著我們必須通過經過高度優化的sql語句（或儲存過程）才能達到系統性能設計指標，在這種情況下Mybatis會有更好的可控性和表現，可以進行細粒度的優化。
openJPA
Toplink/EclipseLink
JDO
學習參考連結：官網
JPA——統一ORM江山
JPA是什麼?
請點選——參考連結
ORM和JPA的關係？
~JPA Java Persistence API，是Java EE 5的標準ORM介面，也是ejb3規範的一部分。
Hibernate，當今很流行的ORM框架，是JPA的一個實現，但是其功能是JPA的超集。
JPA和Hibernate之間的關係，可以簡單的理解為JPA是標準介面，Hibernate是實現。那麼Hibernate是如何實現與JPA的這種關係的呢。Hibernate主要是通過三個元件來實現的，及hibernate-annotation、hibernate-entitymanager和hibernate-core。
hibernate-annotation是Hibernate支援annotation方式配置的基礎，它包括了標準的JPA annotation以及Hibernate自身特殊功能的annotation。
hibernate-core是Hibernate的核心實現，提供了Hibernate所有的核心功能。
hibernate-entitymanager實現了標準的JPA，可以把它看成hibernate-core和JPA之間的介面卡，它並不直接提供ORM的功能，而是對hibernate-core進行封裝，使得Hibernate符合JPA的規範。
hibernate是持久化實現技術,而jpa是持久化的標準,一個是具體實現，一個是介面協議，當然springdata jpa是在hibernate的基礎上更上層的封裝實現。
目前比較成熟的 JPA 框架主要包括 Jboss 的 Hibernate EntityManager、Oracle 捐獻給 Eclipse 社群的 EclipseLink、Apache 的 OpenJPA 等。
請
小結：JPA規範的推出，參考了之前Hibernate的實現方式，主要是想要統一java中ORM的世界，JPA推出後，Hibernate對JPA進行了積極地擁護和實現。
點選——參考連結
ORM方案選擇對比，選型的原則？
請點選——參考部落格