是否不鼓励在 hibernate javabean 中具有“额外”功能？例如，“保存”、“发布”，甚至是静态的“通过 id 获取”方法？以及其他潜在变量，例如锁、铃声和口哨声？
如果是这样，我们应该把这些应该在我们处理的每个对象中都有的额外功能放在哪里？例如，如果我们创建了一个包装类 ArticleWrapper，它包含 POJO Article 作为它自己的私有(private)成员变量，它没有到 Hibernate 的映射，那么它就不会工作，因为 Hibernate 只能得到一个 Articles 列表，而不是一个列表ArticleWrappers 的。
最佳答案
我猜这是因为它们为此遵循了经过良好测试的特定模式，但这并不是处理数据库操作的唯一模式。
你描述的那个听起来更像 Active Record Pattern图案。
一些框架实现了 Active Record，然后它们的对象模型将数据和功能混合在一起，就像您描述的那样。我在 Ruby on Rails Active Records 中看到过这种模式在名为 Django 的 Python 框架中.
在这个模式中，每个领域对象都代表数据库中的一行，并携带数据和行为。
Martin Fowler 在他关于企业应用程序架构模式的书中(以及相应的 catalog page )提到了一些其他众所周知的处理数据源层的方法:
本书和目录深入研究了对象关系映射的许多其他模式。
分层设计
在您使用 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);
}
在此层之上，您很可能会定义某种形式的集成层，以通过多种不同方式向应用程序用户公开此服务层，例如通过 RESTful 或 SOAP Web 服务，或 RMI、EJB 或您知道的任何其他技术在那里。
通过不在您的实体中放置任何类型的逻辑，它们可以很好地满足数据载体的目的，并且可以在必要时在不同的服务层中重复使用。
您可能想看看像Spring Data 这样的框架。促进了这种类型的设计。这让每件作品的去向变得更加清晰。
关于java - 为什么鼓励 java hibernate 映射对象成为 POJO 对象？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25558111/