什麼是持久對象？

Question

我讀了Java EE教程和here我看到這句話在開始時：

實體是一個輕量級的持久域對象。

我已搜索持久性對象但找不到明確的解釋。

究竟是一個持久域對象？

Answer 1

Java EE假設了一個叫做Domain Model的東西。領域模型由表示實體的對象組成，其中Entity是具有與業務相關的身份的事物。 （例如，如果您在銀行工作，則您的域名可能涉及帳戶，客戶，控股和貸款等業務）。

這裏是鮑爾和國王Java持久性報價與Hibernate描述域模型：

3.1.1。分析業務域

軟件開發工作開始於分析問題域 （假設沒有遺留代碼或遺留數據庫已存在）。

在此階段，您在問題領域專家的幫助下確定與軟件系統相關的主要實體 。實體 通常是系統用戶理解的概念：付款， 客戶，訂單，項目，出價等。一些實體可能是 抽象用戶認爲較不具體的東西，如 定價算法，但即使這些通常是 用戶可以理解。所有這些實體都在 業務的概念視圖中找到，我們有時稱之爲業務模型。開發人員和麪向對象軟件架構師分析業務模型，並創建一個面向對象的模型，仍然在概念層面（沒有 Java代碼）。這種模式可能與開發人員心目中僅存在的心理圖像一樣簡單，或者可能與由諸如ArgoUML或TogetherJ的計算機輔助軟件工程（CASE） 工具創建的UML 類圖一樣精細。以UML表示的簡單模型是圖3.1所示的 。

此模型包含您必須在任何典型的 拍賣系統中找到的實體：類別，項目和用戶。這些實體和它們的關係（以及它們的屬性）全部由 這個問題域的模型表示。我們稱這種面向對象爲 模型的實體來自問題域，只包含那些對用戶感興趣的實體，一個域模型。這是一個真實世界的抽象視圖 。

分析和設計域模型 背後的動機目標是捕獲應用程序目的的商業信息的本質。

理想的情況下（在方法稱爲Domain-Driven Design）這些領域對象有2個特點：他們不知道有關的基礎設施的擔憂像持久性或事務，以及它們所包含的邏輯實現，當他們在過程中被操縱發生的狀態轉換業務處理;這些組合意味着業務邏輯可以與基礎架構分開進行測試。在現實世界中，更典型的是看到anemic domain objects不包含任何業務邏輯，業務邏輯全部以transaction scripts結束。

無論如何，這個想法是你有一個由持久實體組成的域模型。有一些配置（註釋或XML文件或其他）將實體及其屬性映射到數據庫中的表和列，並映射實體之間的關係。有一個對象關係映射器（JPA是實現ORM的標準，Hibernate就是這樣一種實現），它知道如何在數據庫表示和對象圖表示之間來回轉換數據，以便開發人員可以改變對象的數據庫行。

對於誰聲稱，業務邏輯不應該是域模型的一部分人來說，這裏是從Java持久性的另一個報價與Hibernate書，第3.1.2節：

中的實體領域模型應該封裝狀態和行爲。 例如，用戶實體應定義客戶的名稱和地址以及計算 項目（對特定客戶）的運輸成本所需的邏輯。領域模型是一個豐富的對象 模型，具有複雜的關聯，交互和繼承 的關係。在領域驅動設計（Evans，2003）中的企業應用架構模式（Fowler，2003）或 中可以找到 用於使用領域模型的面向對象技術的有趣和詳細討論 。

在這本書中，我們不會多說關於業務規則或關於我們領域模型的行爲。這不是因爲我們認爲它不重要，而是 ;相反，這種擔心主要與持久性問題 正交。這是我們實體的狀態是持久的，所以我們集中討論如何在我們的 域模型中最好地表示狀態，而不是如何表示行爲。例如，在這本 書中，我們對如何計算出售物品的稅金沒有興趣，或者 系統如何批准新的用戶帳戶。我們更感興趣的是 ，用戶和他們出售的物品之間的關係是如何表示並持續存在的，如 。我們將在稍後的 章節中重新討論這個問題，只要我們仔細看看分層應用程序設計 以及邏輯和數據訪問的分離。

因此很明顯，Hibernate的開發者認爲這是一個可行的選擇，儘管它似乎並沒有在典型的企業發展的常用方法。

Answer 2

它是一個Domain對象的狀態。

持久實例在數據庫中有一個表示和一個標識符值。它可能只是被保存或加載，但是，它被定義在Session的範圍內。

例如在這裏看到的物體的狀態在Java ORM framework hibernate

免責聲明：這只是一個想法。

Answer 3

我只是補充說這個答案與another question of Koray Tugay有關。

在Java EE中，JPA實體通常是由JPA容器管理的Bean。此容器在任何Java EE認證的應用程序服務器中提供。

每個實體對象都是RDBMS實例中一個或多個表的狀態的內存中表示。事務內的每個狀態修改的managed實體將自動由容器處理並映射爲針對數據庫執行的sql命令。所以你不必關心域模型的持久性部分。只需修改相應的Java對象（實體）狀態，它就會自動反映到數據庫中。 （當然這不是魔術，並配有自己的缺陷。）

每個實體相關聯提供了連接池的其中一個datasource的persistence unit一部分。

持久化單元由許多EntityManager實例管理。 EntityManager負責管理關聯的persistence unit的所有實體的內存中表示;至少是當前從數據庫加載的那些。每個線程通常有一個EntityManager實例（〜每個http請求）。

當使用container-managed EntityManager（與@PersistenceContext注入方式），容器將自動傳播給你持久化單元操作所蘊含的所有的bean（控制器/服務/刀/等）之間的交易環境。

（最後一句意思是在遇到@transactionnal註釋時它會打開一個事務，並且在當前方法調用期間執行的任何bean的每個方法都將成爲同一事務的一部分。方法執行結束）。