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

我看到的現(xiàn)代ORM的一個巨大缺陷是，它們確實希望幫助您解決所有SQL問題。 我是什么意思，為什么我要說這是一個錯誤？ 好吧，我相信Hibernate等人只是太努力了 ，最終提供的功能實際上對開發(fā)人員的傷害大于對他們的幫助。 我所說的主要思想是查詢支持。 ORM中嚴重缺乏對易于維護的復(fù)雜查詢的實際支持，并不是因為它們省略了一些東西，而是因為它們提供的工具沒有使用SQL，而SQL正是為此目的而專門設(shè)計的。

休眠的經(jīng)驗

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

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

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

堅實的ORM的標準

基本上，我對ORM的個人要求可以歸結(jié)為以下幾點：

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

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

一個簡單的功利主義ORM

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

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

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

參考： 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)容還不錯，歡迎將生活随笔推薦給好友。