为什么鼓励java hibernate-mapped对象成为POJO的对象？

在hibernate的javabean中有没有“额外”的功能是不鼓励的？例如，“保存”，“发布”，甚至是静态的“按ID”方法？还有其他潜在的变量，如锁，钟声和哨声？为什么鼓励java hibernate-mapped对象成为POJO的对象？

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

来源

2014-08-28 pete

我猜写代码不仅仅是使它编译和运行。为了使代码干净易维护，开发人员为这种特殊情况提出了各种设计模式，例如DataAccessObject（或dao）。遵循面向对象的良好实践会使开发人员的工作更加高效，特别是如果他们从事大型项目的工作，并且时间代码不具有体面的凝聚力，并且看起来像一桶脏衣服将变得无法维护。请记住 - 仅仅因为你可以做点什么并不意味着你应该这样做。

来源

2014-08-28 21:28:41 Lucas

我对你的模糊答案感到困惑。你在暗示我在这种情况下做什么？ – pete 2014-08-28 21:55:49

如果每个hibernate-mapped对象都需要为每个对象定制额外的功能，比如publish（），那我怎样才能在不把它们放入对象本身的情况下呢？它应该是“访客”的设计模式吗？即使这样也需要增加一些额外的东西，对吧？ – pete 2014-08-28 22:02:40

我想这是因为他们遵循一个特定的测试模式，但这不是处理数据库操作的唯一模式。

你描述的那个听起来更像是Active Record Pattern模式。

一些框架实现Active Record，然后他们的对象模型将数据和功能混合在一起，就像您描述的那样。我在Ruby on Rails Active Records和Python的框架Django中看到过这种模式。

在这种模式中，每个域对象代表数据库中的一行，并同时携带数据和行为。

马丁·福勒在他的企业应用架构模式一书（以及相应的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); 
}

在该层的顶部，则很可能定义某种形式的集成层通过基于REST或SOAP的Web服务在许多不同的方式来公开此服务层到应用程序的用户一样，或者RMI，EJB或任何其他技术你知道那里。通过不在你的实体中放置任何种类的逻辑，它们很好地服务于数据载体的目的，并且如果需要可以在不同的服务层中重用。

你可能想看看像Spring Data这样的框架来促进这种类型的设计。这使得每件作品都应该走的更加清晰。

来源

2014-08-31 19:35:57

为什么鼓励java hibernate-mapped对象成为POJO的对象？

回答

相关问题