在我以前關(guān)于對(duì)象關(guān)系映射工具（ORM）的帖子中，我討論了在處理當(dāng)今常見的ORM（包括Hibernate）時(shí)遇到的各種問題。 其中包括與從POJO生成架構(gòu)有關(guān)的問題，實(shí)際性能和不斷出現(xiàn)的維護(hù)問題。 本質(zhì)上，結(jié)論是ORM可以為您提供大部分幫助，但是需要一種平衡的方法，有時(shí)您只想避免使用ORM的工具集，因此您應(yīng)該能夠在需要時(shí)繞過它。

我看到的現(xiàn)代ORM的一個(gè)巨大缺陷是，它們確實(shí)希望幫助您解決所有SQL問題。 我是什么意思，為什么我要說這是一個(gè)錯(cuò)誤？ 好吧，我相信Hibernate等人只是太努力了 ，最終提供的功能實(shí)際上對(duì)開發(fā)人員的傷害大于對(duì)他們的幫助。 我所說的主要思想是查詢支持。 ORM中嚴(yán)重缺乏對(duì)易于維護(hù)的復(fù)雜查詢的實(shí)際支持，并不是因?yàn)樗鼈兪÷粤艘恍〇|西，而是因?yàn)樗鼈兲峁┑墓ぞ邲]有使用SQL，而SQL正是為此目的而專門設(shè)計(jì)的。

休眠的經(jīng)驗(yàn)

我的經(jīng)驗(yàn)是，當(dāng)您使用HQL之類的功能時(shí)，經(jīng)常會(huì)考慮節(jié)省幾分鐘的時(shí)間，這本身沒有什么問題，但這可能會(huì)導(dǎo)致嚴(yán)重的問題。 根據(jù)我的經(jīng)驗(yàn)，由于錯(cuò)誤修復(fù)或增強(qiáng)功能，您常常經(jīng)常想要或需要用更靈活的方式替換HQL，而這正是麻煩的開始。

我認(rèn)為自己是一位經(jīng)驗(yàn)豐富的開發(fā)人員，并且我為自己（通常）不打破事物而感到自豪-對(duì)我而言，這是優(yōu)秀開發(fā)人員的標(biāo)志之一。 當(dāng)您面臨著剝離一段代碼并大范圍地替換它（例如用SQL替換HQL）時(shí)，您基本上是在替換具有悠久歷史的代碼，這些歷史記錄包括錯(cuò)誤修復(fù)，增強(qiáng)功能和性能調(diào)整。 現(xiàn)在，您有責(zé)任復(fù)制對(duì)此代碼所做的所有更改，并且很可能您不了解更改的全部范圍或過去已糾正的小問題。

請(qǐng)注意，這也適用于Hibernate提供的所有其他查詢方法，包括Query API，以及擴(kuò)展到JPA中的查詢支持。 問題是您不希望解決方案過于脆弱或有限，而必須在以后完全替換。 這意味著，如果您需要恢復(fù)到SQL來完成任務(wù)，那么很有可能首先應(yīng)該這樣做。 相同的概念適用于軟件開發(fā)的所有領(lǐng)域。
因此，如果像Hibernate這樣的ORM中的基本查詢支持不夠好，我們的目標(biāo)是什么？

堅(jiān)實(shí)的ORM的標(biāo)準(zhǔn)

基本上，我對(duì)ORM的個(gè)人要求可以歸結(jié)為以下幾點(diǎn)：

• 架構(gòu)優(yōu)先–從數(shù)據(jù)庫生成模型，而不是相反。 如果您有一種與平臺(tái)無關(guān)的方式來為數(shù)據(jù)庫指定DDL，那很好，但這不是一個(gè)大問題。 從其他某些特定于域的語言或格式生成數(shù)據(jù)庫不會(huì)幫助任何人，并且會(huì)導(dǎo)致設(shè)計(jì)不良的架構(gòu)。
• 僅限于SQL –如果您想幫助我避免編寫代碼，然后為我生成/公開基于密鑰的查詢等。 不要要求我使用您的查詢API或某些新的查詢語言。 SQL是為查詢而發(fā)明的，所以讓我使用正確的工具。
• 給我簡單的方法來從查詢中填充域?qū)ο蟆?這給了我99％的需求，同時(shí)還給了我靈活性。
• 請(qǐng)?jiān)试S我用查詢結(jié)果填充任意Java Bean –不要將我綁定到已知類型的注冊(cè)表中。
• 不要強(qiáng)迫我使用像Hibernate或Spring提供的那樣的典型事務(wù)容器–它們是一場災(zāi)難，而且我從未見過對(duì)它們有意義的實(shí)際用途。 讓我來處理在我的應(yīng)用程序中獲取和釋放連接/事務(wù)的位置–通常，這僅在少數(shù)地方具有明確的語義發(fā)生。 這可以是JDBC的某些抽象版本，但讓我控制它。
• 我的域?qū)ο笾袥]有聰明/神奇的行為–使用Hibernate時(shí)，我花了很多時(shí)間解決相同的舊代理和延遲加載問題。 它們永無止境，無法一勞永逸地解決，這表明存在嚴(yán)重的設(shè)計(jì)問題。

盡管這些觀點(diǎn)對(duì)我來說似乎完全合理，但是我還沒有遇到過任何真正符合我期望的ORM，因此在Carfey，我們推出了自己的小ORM，我不得不說周末的項(xiàng)目以及我們所擁有的只是總體發(fā)展比Hibernate或我使用的其他ORM更加容易和快捷。 它提供什么？

一個(gè)簡單的功利主義ORM

• Java域類是從數(shù)據(jù)庫模式生成的。 尚無平臺(tái)無關(guān)的DDL，但它在我們的TODO列表中。 Bean包括對(duì)子集合，FK引用的支持，但是它們都是惰性的和可選的-Bean支持它，但是如果您不使用它們，則不會(huì)產(chǎn)生影響。 如果需要，可以直接使用ID，也可以使用域?qū)ο蟊旧怼?持久性僅處理持久性臟對(duì)象，并且僅在請(qǐng)求時(shí)才保存-沒有魔術(shù)沖洗行為。
• 生成的域類僅用于持久性！ 將您的業(yè)務(wù)邏輯等置于其他位置。
• SQL用于所有查找，包括主鍵提取和外鍵關(guān)系。 如果需要增強(qiáng)查找，只需竊取生成的SQL并在其上進(jìn)行構(gòu)建即可。 方法和SQL是從任何索引列中自動(dòng)生成的，因此它們都是為您自動(dòng)提供的，并且是類型安全的。 這也向開發(fā)人員發(fā)出警告–如果您的域類中沒有可用的查找，則由于索引不存在，查找性能可能會(huì)變差。
• 可以以類型安全的方式從自定義查詢中填充任何域類-靈活但易于使用。
• 改進(jìn)的類可隱藏標(biāo)準(zhǔn)的JDBC類型（例如Connnection和Statement以簡化易用性，但是我們不會(huì)對(duì)您施加任何事務(wù)語義，因此，您始終可以直接使用直接結(jié)果集處理。
• 一些基本的必需功能，例如連接池，數(shù)據(jù)庫元數(shù)據(jù)，以及很快的數(shù)據(jù)庫從屬故障轉(zhuǎn)移。

Carfey的我們不相信我們創(chuàng)造了一些令人難以置信的新ORM，超越了所有其他工作，如果這是一個(gè)公共項(xiàng)目，我們必須添加許多功能，但是我們所擁有的功能對(duì)我們有用，并且我認(rèn)為我們有正確的方法。 至少，希望我們的經(jīng)驗(yàn)可以幫助您明智地選擇使用首選ORM的方式，而不必花費(fèi)太多時(shí)間來提供工具而不是交付軟件。

最后要說明的是，如果您有滿足上述需求清單的ORM的經(jīng)驗(yàn)，并且您有很好的經(jīng)驗(yàn)，那么我很樂意聽到有關(guān)它的信息，并會(huì)考慮將其用于將來的Carfey項(xiàng)目。

參考： ORM的問題第2部分–來自我們JCG合作伙伴的 查詢 ? Carfey軟件博客上的 Craig Flichel。

翻譯自: https://www.javacodegeeks.com/2012/02/problems-with-orms-part-2-queries.html

總結(jié)

以上是生活随笔為你收集整理的ORM的问题第2部分–查询的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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