再論 ORM

Object-Relationl Mapping，它的做用是在關係型數據庫和對象之間做一個映射。

 

ORM 對象關係映射，這樣說仍是懵。 這裏比較難理解的是 關係 —— 即Relationl ，雖然看起來是形容詞，可是理解爲名稱應該更加合理。固然，也不要糾結這個。能夠這樣理解，對象：java Model，對應一個實體類，關係：關係型數據庫，對應一個數據庫表，映射：就是具體對應關係。ORM 實際上是 更加天然的表述了咱們對事務的描述，相似ER圖（僅僅是概念層面）同樣，對象數據庫的PDM（僅僅是數據庫層面） 文件同樣。 可是ORM 更深了一步，它跨越了 數據庫和 應用程序。 它 更多關注的是 映射。 使得咱們能夠 隱藏某些數據庫的細節，從而 「更加直接的」 經過應用程序來操做數據庫。雖然減輕了某些方面的工做，可是也對咱們的提出了額外的要求， 就是咱們須要來仔細維護這個 「映射」。

 

映射是必不可少的， 咱們一般須要一個 xml 文件來描述這個映射。 固然， 如今JPA 也可使用 註解了。常見的映射種類有：

3、關聯映射模式
3.1一對一關聯模式：在關聯兩端各加一列。
3.2一對多關聯模式：和3.1同樣。若是多這端是有序的，還需加入一列表示序號。
3.3多對多關聯模式：將關聯單獨做一個表。
3.4組合關聯模式：注意級聯式刪除。
3.5反演關聯模式：關聯兩端指向相關的類型，和普通關聯同樣。
3.6成對關聯模式：關聯記錄兩個類間的關係，用交集類表示關聯，表示成一個單獨的表，每一個關聯對應一個表，用外鍵表示它們間的關係。
3.7關聯上的OCL須要分析成對應的存儲過程代碼。
3.8保證關聯的CARDINALITY也須要分析成對應的存儲過程代碼。

映射關係是不少種的，上面也僅僅是一部分而已。 更多的映射，須要特定場景纔有用到。Hibernate 對咱們的這種映射作了不少 封裝工做。

 

在關係型數據庫和業務實體對象之間做一個映射，這樣，咱們在具體的操做業務對象的時候，就不須要再去和複雜的SQL語句打交道，只需簡單的操做對象的屬性和方法。

 

優點

    第一：隱藏了數據訪問細節，「封閉」的通用數據庫交互，ORM的核心。他使得咱們的通用數據庫交互變得簡單易行，而且徹底不用考慮該死的SQL語句。快速開發，由此而來。

    第二：ORM使咱們構造固化數據結構變得簡單易行。在ORM年表的史前時代，咱們須要將咱們的對象模型轉化爲一條一條的SQL語句，經過直連或是DB helper在關係數據庫構造咱們的數據庫體系。而如今，基本上全部的ORM框架都提供了經過對象模型構造關係數據庫結構的功能。這，至關不錯。

 

缺點

    第一：無可避免的，自動化意味着映射和關聯管理，代價是犧牲性能（早期，這是全部不喜歡ORM人的共同點）。如今的各類ORM框架都在嘗試使用各類方法來減輕這塊（LazyLoad，Cache），效果仍是很顯著的。

    第二：面向對象的查詢語言(X-QL)做爲一種數據庫與對象之間的過渡,雖然隱藏了數據層面的業務抽象,但並不能徹底的屏蔽掉數據庫層的設計,而且無疑將增長學習成本.

    第三：對於複雜查詢，ORM仍然力不從心。雖然能夠實現，可是不值的。視圖能夠解決大部分calculated column，case ，group，having,order by, exists，可是查詢條件(a and b and not c and (d or d))。

    世上沒有驢是不吃草的(又想好又想巧,買個老驢不吃草)，任何優點的背後都隱藏着缺點，這是不可避免的。問題在於，咱們是否能容忍缺點。

 

經常使用的ORM框架

   （1）Hibernate  全自動，須要些hql語句

   （2）iBATIS  半自動本身寫sql語句,可操做性強,小巧

   （3）EclipseLink  一個可擴展的支持JPA的ORM框架，供強大的緩存功能，緩存支持集羣。

   （4）Apache OJB等等

   （5）JPA

 

 

顯然， Hibernate  對ORM支持是最好的，mybatis 不是那麼好。ORM 不是銀彈，雖然咱們再也不須要直接面對sql 、jdbc，可是，咱們又多了一個工做，咱們須要管理映射。

對於Hibernate，咱們須要編寫hbm.xml文件。

對於iBATIS  、mybatis ，咱們須要寫 mapper 的 xml文件，xml裏面須要映射 而後還要寫 sql 文件。固然，如今的 tk-mybatis / mybatis-plus 好像不用寫 sql 文件了。

對於JPA，好像就跟 mybatis-plus 同樣的。 （我如今有點搞不清楚二者區別）

ORM（Object Relational Mapping）框架採用元數據來描述對象一關係映射細節，元數據通常採用XML格式，而且存放在專門的對象一映射文件中。


只要提供了持久化類與表的映射關係，ORM框架在運行時就能參照映射文件的信息，把對象持久化到數據庫中。當前ORM框架主要有五種：Hibernate(Nhibernate)，iBATIS，mybatis，EclipseLink，JFinal。
ORM是經過使用描述對象和數據庫之間映射的元數據,在咱們想到描述的時候天然就想到了xml和特性(Attribute).目前的ORM框架中,Hibernate就是典型的使用xml文件做爲描述實體對象的映射框架,而大名鼎鼎的Linq則是使用特性(Attribute)來描述的。

元數據
是描述其它數據的數據 （data about other data），或者說是用於提供某種資源的有關信息的結構數據（structured data）。元數據是描述信息資源或數據等對象的數據，其使用目的在於：識別資源；評價資源；追蹤資源在使用過程當中的變化；實現簡單高效地管理大量網絡化數據；實現信息資源的有效發現、查找、一體化組織和對使用資源的有效管理。

 

ORM與DB Helper Library：

      不少人可能都接觸過這類的helper，每一個公司都有本身的helper。許多Helper提供了不少的強大的功能，封閉交互底層，實體類支持，提供SQL翻譯功能。ORM比之這些Helper只是多提供了一層，他嘗試封閉的自動化的（或是映射文件）來實現關聯。之前，這都是咱們手打的。（靈活替換數據庫也算ORM優勢，）

        問題就在與有些人發現封閉的自動化關聯知足他們須要了，因此ORM對他而言是成功的。而有些人發現封閉的自動化關聯不適合他們的項目，因此ORM被詬病。

          寫到這裏，我想不用多言了。該結束了。

          個人觀點是ORM試圖取代helper，爲此提供了更多的功能。他爲了應付更加嚴格和複雜的企業需求而不斷髮展，在不少狀況下，這些工具開始具備自身的複雜性，使得開發人員必須學習使用它們的詳細規則，並修改組成應用程序的類以知足映射系統的須要，使用它們所面臨的複雜性反而蓋過了所能得到的好處。在咱們的大部分項目中Helper依然是咱們構建數據持久層的主力，ORM或許在有些項目(模塊)中能夠獨攬一切，可是ORM（就目前而言）沒法面對一切考驗。

 

 

參考：

https://blog.csdn.net/zhanghongjie0302/article/details/47344417

https://baike.baidu.com/item/ORM

https://baike.baidu.com/item/ORM%E6%A1%86%E6%9E%B6/15541111

https://blog.csdn.net/sgear/article/details/7408251