不鼓励在休眠 javabean 中使用“额外”功能吗？例如，“保存”、“发布”，甚至静态“通过 id 获取”方法？还有其他潜在变量，例如锁、钟声和口哨？
如果是这样，我们应该将这些应该存在于我们正在处理的每个对象中的额外功能放在哪里？例如，如果我们创建了一个包装器类 ArticleWrapper，它包含 POJO 文章作为它自己的私有成员变量，它没有到 Hibernate 的映射，那么它将无法工作，因为 Hibernate 只能获取文章列表，而不是列表文章包装器。
【问题讨论】：
标签： java hibernate orm javabeans pojo
我猜这是因为它们遵循一个经过充分测试的特定模式，但这不是处理数据库操作的唯一模式。
您描述的那个听起来更像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 这样的框架，它促进了这种类型的设计。它让每件作品的去向更加清晰。
【讨论】：
我想写代码不仅仅是让它编译和运行。为了使代码干净且易于维护，开发人员针对这种特殊情况提出了各种设计模式，例如 DataAccessObject（或 dao）。遵循 OO 的良好实践将使开发人员的工作更有效率，特别是如果他们在处理大型项目时，时间代码不会呈现出良好的凝聚力水平并且看起来像一桶脏衣服将变得无法维护。请记住 - 仅仅因为您可以做某事并不意味着您应该这样做。
【讨论】：