我看過無數的文章和評論（尤其是評論），它們告訴我們ORM（對象關系映射）的概念有多糟糕，糟糕和錯誤。 以下是通常的聲明，以及我對它們的評論：

但是，為什么首先需要一個ORM？ 假設您決定不使用一個。 您編寫查詢并以ResultSet的形式（或使用您所使用語言的任何形式）將結果取回。 您可以在那里通過其名稱訪問每一列。 結果是類型不安全的類似地圖的結構。 但是系統的其余部分需要對象–前端組件需要對象，服務方法需要對象作為參數，等等。這些對象是簡單的值對象，并且通過getter公開它們的狀態沒有錯。 他們沒有對狀態進行操作的任何邏輯，它們只是用來轉移狀態。 如果您使用的是靜態類型的語言，則很可能在代碼周圍使用對象而不是類型不安全的結構，更不用說這些結構是數據庫訪問接口，并且您不會在前端使用它們碼。 因此，您想到了一個絕妙的主意–“我將創建一個價值對象，并將結果集中的所有內容轉移給它。 現在，我將數據保存在一個對象中，不需要在數據庫中傳遞特定于接口的接口來傳遞代碼。” 這是偉大的一步。 但是很快您就意識到這是一項重復性的任務–您正在創建一個新對象，并逐字段手動進行操作，將結果從SQL查詢傳遞到該對象。 然后，您設計了一個巧妙的反射實用程序，該實用程序可以讀取對象字段，并假定您在數據庫中具有相同的列名，讀取結果集并填充對象。 好吧，猜猜是什么–多年來，ORM一直在做同樣的事情。 我敢打賭他們的更好，并且可以在許多您認為不需要的場景中工作。 （而且我只是簡單地說明了維護本地查詢的過程有多奇怪-有些將它們放在一個巨大的文本文件中（難看），而另一些則將它們放在行內（DBA現在如何優化它們？））

總結上一段–您將在項目中創建某種ORM，但是您的項目將比那里吸收的更多，并且您不會承認它是ORM。

這是提到稱為commons-dbutils （Java）的實用程序的好地方。 它是將數據庫結果映射到涵蓋基本情況的對象的簡單工具。 它不是ORM，但它執行ORM的工作–將數據庫映射到您的對象。 但是基本的列到字段映射器中缺少一些東西，那就是外鍵和聯接。 使用ORM，即使需要JOIN來獲取它，也可以在“地址”字段中獲取用戶的地址。 這既是ORM的優點，也是主要的缺點。 * ToOne映射通常是安全的。 但是* ToMany集合可能非常棘手，并且經常被濫用 。 這部分是ORM的錯誤，因為ORM不會以任何方式警告您映射某個公司的所有訂單的集合的后果。 您將永遠也永遠不需要訪問該集合，但是可以對其進行映射。 我從未從ORM反對者那里聽到過這樣的爭論，因為他們還沒有達到這一點。

那么，ORM基本上是dbutils加上危險的集合映射嗎？ 不，它為您提供了許多所需的其他功能。 方言–您以與數據庫無關的方式編寫代碼，盡管您可能不會更改最初選擇的數據庫供應商，但是使用任何數據庫都容易得多，而無需每個開發人員都了解語法的罪魁禍首。 我曾經使用過MSSQL和Oracle，但與他們合作幾乎沒有痛苦。 另一個非常非常重要的事情是緩存。 您會執行兩次相同的查詢嗎？ 我猜不是，但是如果碰巧是在第三個方法調用的兩個單獨的方法中，則可能很難捕獲或避免。 會話緩存來了，它將為您保存所有重復的查詢，以便從數據庫中獲取某些行（對象）。 這里對ORM還有另一種批評–會話管理太復雜了。 我主要使用JPA，因此我無法透露其他信息，但是正確地進行會話管理確實很棘手。 都是出于很好的理由（前面提到的緩存，事務管理，延遲映射等），但是它仍然太復雜了。 您需要團隊中至少有一個對特定ORM有豐富經驗的人員來正確地進行設置。

但是還有二級緩存，這要重要得多。 這種事情可以使facebook和twitter之類的服務存在–將很少變化的數據填充到（分布式）內存中，而不是每次都查詢數據庫，而是從內存中獲取對象，這快了很多倍。 為什么這與ORM相關？ 因為通常可以將緩存解決方案插入ORM，并且您可以將ORM生成的對象完全存儲在內存中。 通過這種方式，緩存對您的數據庫訪問代碼變得完全透明，從而使其簡單而高效。

因此，總而言之– ORM仍在做您需要做的事情，但是幾乎可以肯定的是，存在10年的框架比您自己的映射器要好，并且它們在頂部提供了許多必要且重要的附加功能他們的核心功能。 他們也有兩個弱點（他們實際上都說“您需要知道自己在做什么”）：

我從未見過將這兩個用作反對ORM的論據，而本文開頭的錯誤用法卻經常被使用，這使我相信，對ORM狂熱的人們很少知道他們在說什么。

參考： ORM Haters不要從Bozho的技術博客博客上的JCG合作伙伴 Bozhidar Bozhanov那里 得到它 。