Question

不鼓励在hibernate javabean中使用“额外”功能吗？例如，“保存”，“发布”，甚至静态“get by id”方法？还有其他潜在的变量，如锁，铃铛和口哨？

如果是这样，我们应该在哪里放置应该在我们正在处理的每个对象中的这些额外功能？例如，如果我们创建了一个包装类ArticleWrapper，其中包含POJO文章作为其自己的私有成员变量，它没有映射到Hibernate，那么它将无法工作，因为Hibernate只能获取文章列表，而不是列表ArticleWrappers。

Answer 1

我想这是因为它们遵循特定的经过良好测试的模式，但这并不是处理数据库操作的唯一模式。

您描述的那个听起来更像是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这样促进此类设计的框架。它使得每件作品都更加清晰。

Answer 2

我想编写代码不仅仅是为了编译和运行。为了使代码干净且易于维护，开发人员已针对此特定情况提出了各种设计模式，例如DataAccessObject（或dao）。遵循OO良好实践将使开发人员＆＃39;工作效率更高，特别是如果他们在大型项目上工作，时间代码没有提供良好的凝聚力，看起来像一桶脏衣服将无法维持。记住 - 只因为你能做某事并不意味着你应该这样做。

为什么鼓励Java hibernate映射对象成为POJO？

2 个答案: