orm查詢部分字段

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

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

Hibernate的經驗

我的經驗是，當您使用HQL之類的功能時，經常會考慮將自己節省幾分鐘，這本身并沒有什么問題，但這會引起嚴重的問題。 根據我的經驗，由于錯誤修復或增強功能，您最終常常想要或需要用更靈活的方式替換HQL，而這正是麻煩的開始。

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

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

堅實的ORM的標準

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

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

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

一個簡單的功利主義ORM

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

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

最后要說明的是，如果您有滿足我上面要求列表的ORM的經驗，并且您有很好的經驗，那么我很樂意聽到有關它的信息，并考慮將其用于將來的Carfey項目。

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

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

orm查詢部分字段

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。