1.平凡之路-ORM概述

1.什麼是ORM ?

　　

• 對象關係映射（Object Relational Mapping，簡稱ORM）是一種爲了解決面向對象與關係數據庫存在的互不匹配的現象的技術。 簡單的說，ORM是經過使用描述對象和數據庫之間映射的元數據，將Java程序中的對象自動持久化到關係數據庫中。本質上就是將數據從一種形式轉換到另一種形式。 這也同時暗示者額外的執行開銷；然而，若是ORM做爲一種中間件實現，則會有不少機會作優化，而這些在手寫的持久層並不存在。 更重要的是用於控制轉換的元數據須要提供和管理；可是一樣，這些花費要比維護手寫的方案要少；並且就算是遵照ODMG規範的對象數據庫依然須要類級別的元數據。

• 對象-關係映射（Object/Relation Mapping，簡稱ORM），是隨着面向對象的軟件開發方法發展而產生的。面向對象的開發方法是當今企業級應用開發環境中的主流開發方法，關係數據庫是企業級應用環境中永久存放數據的主流數據存儲系統。對象和關係數據是業務實體的兩種表現形式，業務實體在內存中表現爲對象，在數據庫中表現爲關係數據。內存中的對象之間存在關聯和繼承關係，而在數據庫中，關係數據沒法直接表達多對多關聯和繼承關係。所以，對象-關係映射(ORM)系統通常以中間件的形式存在，主要實現程序對象到關係數據庫數據的映射。

• 面向對象是從軟件工程基本原則(如耦合、聚合、封裝)的基礎上發展起來的，而關係數據庫則是從數學理論發展而來的，兩套理論存在顯著的區別。爲了解決這個不匹配的現象,對象關係映射技術應運而生。

• 讓咱們從O/R開始。字母O起源於"對象"(Object),而R則來自於"關係"(Relational)。幾乎全部的程序裏面，都存在對象和關係數據庫。在業務邏輯層和用戶界面層中，咱們是面向對象的。當對象信息發生變化的時候，咱們須要把對象的信息保存在關係數據庫中。

• 當你開發一個應用程序的時候(不使用O/R Mapping),你可能會寫很多數據訪問層的代碼，用來從數據庫保存、刪除、讀取對象信息等等。你在DAO中寫了不少的方法來讀取對象數據，改變狀態對象等等任務，而且這些代碼寫起來老是重複的。

解決方案，引入一個O/R Mapping。實質上，一個O/R Mapping會爲你生成DAO。與其本身寫DAO代碼，不如用O/R Mapping。你用O/R Mapping保存、刪除、讀取對象，O/R Mapping負責生成SQL，你只須要關心對象就好。

2.ORM組成

• 一個對持久類對象進行CRUD操做的API；

• 一個語言或API用來規定與類和類屬性相關的查詢；

• 一個規定mapping metadata的工具；

• 一種技術可讓ORM的實現同事務對象一塊兒進行dirty checking, lazy association fetching以及其餘的優化操做。

3.持久化的概念

狹義的理解：「持久化」僅僅指把域對象永久保存到數據庫中；
廣義的理解：「持久化」包括和數據庫相關的各類操做(持久化就是將有用的數據以某種技術保存起來,未來能夠再次取出來應用,數據庫技術,將內存數據一文件的形式保存在永久介質中(磁盤等)都是持久化的例子)。

• 保存：把域對象(或者實體Bean)永久保存到數據庫。

• 更新：更新數據庫中域對象(或者說持久化對象)的狀態。

• 刪除：從數據庫中刪除一個域對象。

• 加載：根據特定的OID(通常是指主鍵ID)，把一個域對象從數據庫加載到內存。

• 查詢：根據特定的查詢條件，把符合查詢條件的一個或多個域對象從數據庫加載內在存中。

4.爲何使用持久化?

• 持久化技術封裝了數據訪問細節，爲大部分業務邏輯提供面向對象的API。

• 經過持久化技術能夠減小訪問數據庫數據次數，增長應用程序執行速度

• 代碼重用性高，可以完成大部分數據庫操做；

• 鬆散耦合，使持久化不依賴於底層數據庫和上層業務邏輯實現，更換數據庫時只需修改配置文件而不用修改代碼。

5.有哪些ORM產品?

目前衆多廠商和開源社區都提供了持久層框架的實現，常見的有：
Apache OJB | Cayenne | Jaxor | Hibernate | iBatis[MyBatis] | JPA等等

• Hibernate 的輕量級 ORM 模型逐步確立了在 Java ORM 架構中領導地位，甚至取代複雜而又繁瑣的 EJB 模型而成爲事實上的 Java ORM 工業標準。並且其中的許多設計均被 J2EE 標準組織吸納而成爲最新 EJB 3.0 規範的標準，這也是開源項目影響工業領域標準的有力見證。

• JPA（Java Persistense API）是EJB3.0的一部分，爲其提供了一套O/R關係映射的API，但不只限於EJB中使用，它也能夠在web應用或者應用程序客戶端中被使用，甚至在Java桌面程序中被使用。

• iBATIS/MyBatis 的着力點，則在於POJO 與SQL之間的映射關係。而後經過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。 相對Hibernate「O/R」而言，iBATIS 是一種「Sql Mapping」的ORM實現。

6.MyBatis和Hibernate的區別

• 1.Hibernate是全自動，而MyBatis是半自動 [簡單理解]
  Hibernate徹底能夠經過對象關係模型實現對數據庫的操做，擁有完整的JavaBean對象與數據庫的映射結構來自動生成SQL語句。而MyBatis僅有基本的字段映射，對象數據以及對象實際關係仍然須要經過定製SQL語句來實現和管理。

• 2.Hibernate數據庫移植性遠大於MyBatis
  Hibernate經過它強大的映射結構和hql語言，大大下降了對象與數據庫（Oracle、MySQL等）的耦合性，而MyBatis因爲須要手寫sql，所以與數據庫的耦合性直接取決於程序員寫SQL的方法，若是SQL不具通用性而用了不少某數據庫特性的sql語句的話，移植性也會隨之下降不少，成本很高。

• 3.Hibernate擁有完整的日誌系統，MyBatis則欠缺一些
  Hibernate日誌系統很是健全，涉及普遍，包括：SQL記錄、關係異常、優化警告、緩存提示、髒數據警告等；而MyBatis則除了基本記錄功能外，功能薄弱不少。

• 4.MyBatis相比Hibernate須要關心不少細節
  Hibernate配置要比MyBatis複雜的多，學習成本也比MyBatis高。但也正由於MyBatis使用簡單，才致使它要比Hibernate關心不少技術細節。MyBatis因爲不用考慮不少細節，開發模式上與傳統jdbc區別很小，所以很容易上手並開發項目，但忽略細節會致使項目前期bug較多，於是開發出相對穩定的軟件很慢，而開發出軟件卻很快。Hibernate則正好與之相反。可是若是使用Hibernate很熟練的話，實際上開發效率絲絕不差於甚至超越MyBatis。

• 5.SQL直接優化上，MyBatis要比Hibernate方便不少

我的認爲：這也是不少公司選擇它的重要緣由！

因爲MyBatis的sql都是寫在xml裏，所以優化sql比Hibernate方便不少。而Hibernate的sql不少都是自動生成的，沒法直接維護sql；雖有hql，但功能仍是不及sql強大，見到報表等變態需求時，hql也歇菜，也就是說hql是有侷限的；hibernate雖然也支持原生sql，但開發模式上卻與orm不一樣，須要轉換思惟，所以使用上不是很是方便。總之寫sql的靈活度上Hibernate不及MyBatis。

• 6.安全性安全性，Hibernate是預編譯的，MyBatis可能存在SQL注入問題，另外使用Hibernate對數據庫類型進行切換時，成本明顯低於MyBatis