Hibernate已成為Java生態(tài)系統(tǒng)中的事實(shí)上的標(biāo)準(zhǔn)，事實(shí)上， 如果標(biāo)準(zhǔn)對您很重要 ，并且如果您將JCP與ISO，ANSI，IEEE等置于同一級別，那么Hibernate也是實(shí)際的JavaEE標(biāo)準(zhǔn)實(shí)現(xiàn)。

本文的目的不是討論標(biāo)準(zhǔn)，而是討論愿景。 Hibernate贊同JPA對ORM的看法。 jOOQ擁有SQL強(qiáng)大查詢的愿景，因此，為了爭辯，讓我們像jOOQ / JDBC / SQL一樣互換使用Hibernate / JPA / ORM。

為什么現(xiàn)在不應(yīng)該使用Hibernate的問題總是經(jīng)常出現(xiàn) -正是因?yàn)镠ibernate是事實(shí)上的標(biāo)準(zhǔn)，并且是許多其他框架（例如Grails（ 使用GORM，又使用Hibernate ））中的第一個框架選擇。

但是，即使是Hibernate的創(chuàng)建者Gavin King，也不相信Hibernate應(yīng)該用于所有方面 ：

如果是這樣，您是否可以考慮任何客觀的決策幫助點(diǎn)，何時使用ORM以及何時使用SQL？

高水平的討論

首先，讓我們將討論提高到更高的水平。 與其在Hibernate和jOOQ之間確定它們各自域的具體實(shí)現(xiàn)，不如考慮ORM與SQL以及它們的不同用例。

在確定ORM（例如Hibernate）和SQL（例如jOOQ）之間時，您應(yīng)該問自己的驅(qū)動問題不是項(xiàng)目復(fù)雜性問題。 我們一些最苛刻的客戶正在對具有數(shù)千個表/視圖的中型架構(gòu)使用jOOQ。 通常，這些模式被高度標(biāo)準(zhǔn)化，有時甚至部署在多達(dá)六個不同的RDBMS上。 jOOQ專為在這些情況下工作而設(shè)計(jì)，同時也牢記了簡單的用例。

因此，與其考慮項(xiàng)目的復(fù)雜性，不如問自己以下問題：

您的數(shù)據(jù)模型將驅(qū)動您的應(yīng)用程序設(shè)計(jì)，還是您的應(yīng)用程序設(shè)計(jì)將驅(qū)動您的數(shù)據(jù)模型？
這里的一個主要方面是從數(shù)據(jù)庫是否可以在應(yīng)用程序中生存下來的角度來考慮您是否“關(guān)心”數(shù)據(jù)庫的問題。 很多時候，應(yīng)用程序來來往往。 它們可能會用Python / JavaScript等進(jìn)行重寫，直到5年后。 或者，您有多個應(yīng)用程序訪問同一個數(shù)據(jù)庫：Java應(yīng)用程序，一些Perl腳本，存儲過程等。在這種情況下，數(shù)據(jù)庫設(shè)計(jì)是您項(xiàng)目中的優(yōu)先事項(xiàng)，而jOOQ在這些設(shè)置中工作得非常好。從某種意義上說，您不一定要“關(guān)心”您的數(shù)據(jù)庫，而只是想在某個地方“持久化”您的Java域，而這恰好是一個關(guān)系數(shù)據(jù)庫，那么Hibernate也許是一個更好的選擇-至少在項(xiàng)目的早期階段，因?yàn)槟梢暂p松地從Entity模型生成數(shù)據(jù)庫架構(gòu)。

您將主要從事復(fù)雜的閱讀和簡單的寫作，還是從事復(fù)雜的寫作？
當(dāng)閱讀很復(fù)雜時，SQL才真正發(fā)揮作用。 當(dāng)您聯(lián)接許多表時，當(dāng)您在數(shù)據(jù)庫中聚合數(shù)據(jù)時，當(dāng)您進(jìn)行報(bào)告時，當(dāng)您進(jìn)行批量讀取和寫入時。 您是從集合論的角度來考慮數(shù)據(jù)的，例如您的數(shù)據(jù)整體。 但是，用SQL編寫CRUD很無聊。 這就是為什么jOOQ還為您提供了一個ActiveRecord風(fēng)格的API，該API在處理單個表時會處理無聊的部分（Jason提到過）。但是，如果您的編寫變得復(fù)雜，即您必須加載一個復(fù)雜的對象圖，其中包含20個涉及內(nèi)存的實(shí)體，對其進(jìn)行樂觀鎖定，以多種不同方式對其進(jìn)行修改，然后再次將其持久保存，那么SQL / jOOQ將無濟(jì)于事。 這就是Hibernate最初創(chuàng)建的目的。

意見

我相信數(shù)據(jù)是永遠(yuǎn)的。 您應(yīng)該*始終*假定數(shù)據(jù)庫在應(yīng)用程序中仍然存在。 重寫應(yīng)用程序（的一部分）比遷移數(shù)據(jù)庫要容易得多。 擁有一個干凈且設(shè)計(jì)良好的數(shù)據(jù)庫架構(gòu)將始終使項(xiàng)目，特別是復(fù)雜項(xiàng)目的收益得到回報(bào)。 另請參閱我們先前有關(guān)“無模式”數(shù)據(jù)庫的謬誤的文章 。

而且，大多數(shù)項(xiàng)目實(shí)際上完成90％的讀取和10％的寫入，寫入通常并不復(fù)雜（在事務(wù)中修改2-3個表）。 這意味著大多數(shù)情況下，不需要Hibernate / JPA的一級和二級緩存解決的復(fù)雜性。 人們常常會誤解這些功能，而只是關(guān)閉緩存，將Hibernate的緩存一直刷新到服務(wù)器，從而以錯誤的方式使用Hibernate。

但是，如果您不確定上述兩個決策軸，則可以走中間路線，僅將jOOQ用于報(bào)告，批處理等，并將Hibernate用于CRUD –在CQRS（命令查詢職責(zé)隔離）中： http://martinfowler.com/bliki/CQRS.html ）樣式。 也有很多jOOQ用戶選擇了此路徑。

進(jìn)一步閱讀

• 吞吐量與復(fù)雜性–什么時候應(yīng)該使用ORM？ 由Mike Hadlow
• 為什么要使用ORM？ 比爾·卡文（Bill Karwin）
• 是否有充分的理由不使用ORM？ 堆棧溢出
• 為什么要使用ORM？ 堆棧溢出

翻譯自: https://www.javacodegeeks.com/2015/03/jooq-vs-hibernate-when-to-choose-which.html

總結(jié)

以上是生活随笔為你收集整理的jOOQ与Hibernate：何时选择哪个的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。