JPA POJO作爲數據對象

Question

使用JPA實體的最佳做法是什麼？

由於JPA實體只是POJO，因此認爲在系統的其他部分將該對象用作數據對象是合適的，還是應該將它們轉換爲另一個數據對象？

在與JPA無關的系統的其他部分使用JPA實體POJO是否可以接受？

Answer 1

實體現在自己能夠傳輸自己的數據，所以爲什麼要把它們轉換成別的東西呢？換句話說，我傾向於DTO an AntiPattern in EJB 3.0同意：

在之前的EJB 3.0 EJB規範的重物性質的實體bean，導致了設計模式，如Data Transfer Objects（DTO）的使用。 DTO成爲輕量級對象（本來應該是實體bean本身），用於跨層發送數據。 [...]

EJB 3.0規範使實體bean模型與普通舊Java對象（PO​​JO）相同。有了這個新的POJO模型，您將不再需要爲每個實體或一組實體創建DTO。如果您想跨層發送EJB 3.0實體，則只需執行java.io.Serialiazable。

Answer 2

這取決於你的意思是「其他部分」。由於你的JPA實體必須與你的系統有某種關係，爲什麼不使用它們呢，因爲它們已經在那裏了。重要的一點是，你不會將兩個完全不同的問題用於同一個班級（這是因爲設計不好或只是一個非常大的系統）。其他任何事情都可能最終會導致您在不同的POJO麻煩之間進行無盡的映射。

例如用戶登錄。爲基於Web的登錄創建一個單獨的UserLoginForm Bean可能是常見的煩惱，但考慮到這一點：

您已經擁有數據庫中的用戶JPA實體（因此是用戶POJO）（它有一個用戶名，密碼哈希，地址和其他可能存儲的東西）。您可以在Web表單中使用與您的登錄請求中完全相同的對象（一些類似Spring的框架將立即映射）。創建一個空的User對象，設置用戶名和哈希密碼，並通過示例進行JPA查詢。如果該查詢只返回一個結果，則登錄有效，並且可以將加載的用戶對象存儲在會話中。

Answer 3

這是一個很好的問題。

通過將JPA實體類暴露給系統的其餘部分，您將持久性機制和對象暴露給數據庫映射。您將失去對這些對象如何被控制和管理的控制權。通過打破持久性封裝，更改可能會對系統的其他部分產生連鎖反應。

系統持久性的未來變化可能是不可能的，尷尬的，有限的和/或有風險的。例如：您可能需要針對性能和/或可伸縮性進行優化。這可能需要緩存，數據庫模式更改，非RDBMS使用情況以及多個數據庫。封裝還有助於減輕向未來db架構的遷移。

所以權衡是：

• 管理和維護上JPA之上的應用的持久層，它封裝持久性。即一個接口。或
• 決定在您的架構中全面使用JPA。接受未來的變化可能會產生全系統影響的事實。

如果頻繁的系統範圍變化是不可接受的，則第一種選擇可能是必需的 - 例如，第三方正在訪問您的數據。或者您可能已經決定採用3層架構：GUI，業務邏輯，持久性。

如果您有一個敏捷開發流程，並且能夠控制整個系統並接受系統範圍內可能需要更改的事實，那麼第二種選擇是可以的。