orm框架選型問題

在過去的幾年中，像Hibernate這樣的對象關(guān)系映射工具已經(jīng)幫助開發(fā)人員在處理關(guān)系數(shù)據(jù)庫方面獲得了巨大的生產(chǎn)力增長。 ORM使開發(fā)人員可以專注于應(yīng)用程序邏輯，并避免為諸如插入或查詢之類的簡單任務(wù)編寫大量樣板SQL。

但是，充分證明的對象關(guān)系阻抗不匹配問題不可避免地引起開發(fā)人員的頭痛。 關(guān)系數(shù)據(jù)庫是建立在合理概念基礎(chǔ)上的一種專門技術(shù)，但是它們不一定符合面向?qū)ο蟮氖澜纭?有幾種使用ORM的方法和樣式，它們各有利弊。

使用ORM的基本選擇之一是確定是從數(shù)據(jù)庫架構(gòu)生成ORM映射，還是從數(shù)據(jù)庫架構(gòu)生成ORM定義（可能是XML配置文件，注釋或類似XDoclet之類的數(shù)據(jù)庫架構(gòu)） ）。

從數(shù)據(jù)庫架構(gòu)生成ORM層的前一種方法意味著，無論是處理特定于數(shù)據(jù)庫的DDL還是具有某些抽象層，都必須使用其自己的語言和術(shù)語來處理數(shù)據(jù)庫，但是仍然不得不處理數(shù)據(jù)庫本身。 不幸的是，這意味著您需要技術(shù)方面的專業(yè)知識，并且可能要花費比允許生成架構(gòu)更多的工作。 但是，這迫使開發(fā)人員正確理解和處理RDBMS –將DBMS視為簡單數(shù)據(jù)存儲區(qū)既危險又有害。 開發(fā)人員在設(shè)計應(yīng)用程序時需要考慮鍵，索引等的影響，并將它們與關(guān)系數(shù)據(jù)庫的現(xiàn)實掩蓋起來可能很危險，而根據(jù)我的經(jīng)驗，這總是很糟糕的。 一個相關(guān)的問題是POJO的使用，最終由ORM框架操縱。 從理論上講，這聽起來不錯，但實際上您會遇到各種各樣的問題，并且很可能將應(yīng)用程序邏輯與真正應(yīng)該構(gòu)成數(shù)據(jù)訪問對象的邏輯混合在一起。 開發(fā)人員和架構(gòu)師喜歡通過使用Spring和其他框架來贊揚關(guān)注點的分離，并且沒有真正的理由為什么不應(yīng)在此處應(yīng)用相同的概念。 另一個較小的問題是需要維護POJO和映射定義，但這通常不是太多的工作。

從您的模式生成ORM映射和代碼的第二種方法是我的首選方法。 根據(jù)我使用這兩種方法的經(jīng)驗，可以從模式中生成bean，從而可以智能地設(shè)計bean，并且僅根據(jù)需要使其變得復(fù)雜，同時可以免費按PK，按索引等進行獲取。 由于它們都在持久性類本身中進行管理，因此管理惰性集合和引用對象之類的事情也變得更加容易。 這種方法還避免了編寫樣板POJO的需要，并迫使您將數(shù)據(jù)訪問對象與域?qū)ο蠛蜆I(yè)務(wù)邏輯分開對待。 根據(jù)我從架構(gòu)生成數(shù)據(jù)訪問bean的經(jīng)驗，這些bean最終變得更豐富，更可用，性能更好，并且一旦建立了基礎(chǔ)架構(gòu)，維護成本就會降低。 有人可能會認為您最終需要其他數(shù)據(jù)包裝器類，但實際上，對單獨的Bean類的需求與數(shù)據(jù)訪問層中發(fā)生的情況無關(guān)。 這里的一個問題是可以為您完成這一代工作的框架的可用性–過去，我曾使用過定制的解決方案，這些解決方案雖然效果很好并取得了回報，但是需要初期的前期工作。 在較小的項目上，可能沒有足夠的回報值得在這種工作上進行投資。 同時，有一些采用這種方法并生成持久性實體類的ORM ，例如jooq ，但是我必須嘗試一下。

Hibernate是Java領(lǐng)域中最流行的ORM，盡管它與處理大量SQL無關(guān)，但它存在一些問題。 通常，該方法是定義映射和POJO，然后讓Hibernate管理SQL生成。 這樣做的問題是您定義的架構(gòu)通常不理想，并且最終忽略了諸如正確索引之類的事情。 盡管您選擇使用其專有內(nèi)容的程度由您決定，但Hibernate還會迫使您最終使用其事務(wù)和查詢機制。 這不一定在所有情況下都是一件壞事，但是我個人對經(jīng)常使用的HQL語言感到不滿意，因為它為開發(fā)人員引入了一種熟悉的，不同的語言，其他人后來不得不維護并嘗試弄清楚出來。 查詢優(yōu)化也可能出現(xiàn)問題，并且過去在性能調(diào)優(yōu)方面做了大量工作，對我來說，必須訪問實際查詢以進行調(diào)優(yōu)。 我還認為，嘗試在持久性類中實現(xiàn)繼承只是一個壞主意–試圖將一個概念強加到自然無法容納它的技術(shù)上是不值得的。 Hibernate誘使開發(fā)人員通過支持按層次結(jié)構(gòu)表和按類的機制在數(shù)據(jù)庫中實現(xiàn)繼承，但這在我心中是一個錯誤，因為您最終會遇到不良的數(shù)據(jù)模型以及以后管理和擴展層次結(jié)構(gòu)的問題。 我也不喜歡填充應(yīng)該是干凈的關(guān)系模型-您不能假裝關(guān)系數(shù)據(jù)庫是面向?qū)ο蟮臄?shù)據(jù)存儲。

如果您從這篇文章中刪除了一件事，那就應(yīng)該是不要忽略您正在使用的實際技術(shù)。 對待RDBMS到底是什么，然后學(xué)習(xí)使用它。 對面向?qū)ο蟮南到y(tǒng)執(zhí)行相同的操作。 無論如何，請嘗試通過使用ORM來避免編寫樣板代碼和不必要SQL，從而使您的生活更輕松，但是不要認為您可以避免處理某種翻譯或代碼來應(yīng)對自然發(fā)生的不匹配。 不要期望使用框架或工具來為您解決問題。 開發(fā)人員付錢去思考和辨別最好的道路，因此我們不應(yīng)該害怕在問題出現(xiàn)時以明智的方式處理它們。 與許多事物一樣，此處適用80-20規(guī)則。 使用ORM可以為您完成80％的工作，并準(zhǔn)備為另外20％的工作編寫SQL和一些持久性代碼。 不要期望太高，否則您最終會遇到幾種類型的問題-奇怪的錯誤，性能問題，設(shè)計不良的面向?qū)ο竽Ｐ偷取?

我很想聽聽您對任何語言的ORM的經(jīng)驗和想法以及您所面臨的問題，以及如何處理它們。 這是經(jīng)驗非常寶貴的主題之一，因此請分享您的想法。

參考： 問題與奧姆斯我們JCG伙伴 ■在Carfey軟件博客 。

相關(guān)文章 ：

• Hibernate陷阱
• Hibernate自動提交命令強制MySQL在過多的磁盤I / O中運行
• Hibernate映射集合性能問題
• DataNucleus 3.0與Hibernate 3.5
• Java Persistence API：快速入門

翻譯自: https://www.javacodegeeks.com/2011/09/problems-with-orms.html

orm框架選型問題

總結(jié)

以上是生活随笔為你收集整理的orm框架选型问题_ORM问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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