爲什麼鼓勵java hibernate-mapped對象成爲POJO的對象？

Question

在hibernate的javabean中有沒有「額外」的功能是不鼓勵的？例如，「保存」，「發佈」，甚至是靜態的「按ID」方法？還有其他潛在的變量，如鎖，鐘聲和哨聲？

如果是這樣，我們應該在哪裏放置這些額外的功能，應該在我們正在處理的每個對象中？例如，如果我們創建了一個包裝類ArticleWrapper，它包含POJO文章作爲它自己的私有成員變量，它沒有映射到Hibernate，那麼它將無法工作，因爲Hibernate只能獲取文章列表，而不是列表ArticleWrappers。

Answer 1

我猜寫代碼不僅僅是使它編譯和運行。爲了使代碼乾淨易維護，開發人員爲這種特殊情況提出了各種設計模式，例如DataAccessObject（或dao）。遵循面向對象的良好實踐會使開發人員的工作更加高效，特別是如果他們從事大型項目的工作，並且時間代碼不具有體面的凝聚力，並且看起來像一桶髒衣服將變得無法維護。請記住 - 僅僅因爲你可以做點什麼並不意味着你應該這樣做。

Answer 2

我想這是因爲他們遵循一個特定的測試模式，但這不是處理數據庫操作的唯一模式。

你描述的那個聽起來更像是Active Record Pattern模式。

一些框架實現Active Record，然後他們的對象模型將數據和功能混合在一起，就像您描述的那樣。我在Ruby on Rails Active Records和Python的框架Django中看到過這種模式。

在這種模式中，每個域對象代表數據庫中的一行，並同時攜帶數據和行爲。

馬丁·福勒在他的企業應用架構模式一書（以及相應的catalog page）提到了其他一些衆所周知的方法來處理你的數據源層：

• Table Data Gateways
• Row Data Gateway
• Data Mapper
• Active Record

本書和目錄深入研究了許多其他對象關係映射模式。

分層設計

在你使用Hibernate描述的經典方式，實體數據只是佔位符，但不包含任何邏輯。在這種模式下，您很可能會在實體周圍建立數據訪問層或存儲庫層，以處理從基礎數據源恢復實體並將其更新回來。

該圖層是處理CRUD operations的圖層。

interface ArticleRepository { 
    Article findById(Integer articleId); 
    List<Article> findByAuthor(Integer authorId); 
    Article save(Article article); 
    void delete(Integer articleId); 
} 

在該層的頂部，你有一個服務層，它暴露出業務邏輯到應用程序的用戶之一。

interface ArticleService { 
    void publishArticle(String author, Date date, String title, String contents); 
    List<Article> getFeaturedArticles(Date date); 
    void unpublishArticle(Integer articleId); 
} 

在該層的頂部，則很可能定義某種形式的集成層通過基於REST或SOAP的Web服務在許多不同的方式來公開此服務層到應用程序的用戶一樣，或者RMI，EJB或任何其他技術你知道那裏。通過不在你的實體中放置任何種類的邏輯，它們很好地服務於數據載體的目的，並且如果需要可以在不同的服務層中重用。

你可能想看看像Spring Data這樣的框架來促進這種類型的設計。這使得每件作品都應該走的更加清晰。