【问题标题】:What's the point of having complex entity classes (in the Hibernate sense)拥有复杂的实体类有什么意义(在 Hibernate 意义上)
【发布时间】:2011-10-04 18:32:40
【问题描述】:

既然经典的 OOP 模型无论如何都被打破了,尽管 ORM 有这么多好东西,为什么我需要在我的实体类中注释以下两个示例属性:

User
   => Collection<Photo> photos (one to many)
   => Collection<User> friends (one to many)

因为我不会使用那些......永远。看起来,我需要做一些分页或其他类型的格式化,所以我想我总是会选择类似的东西:

photoDAOInstance.find(searchCriteria); 

我为什么不简单地将实体类的注释限制为仅对应数据库表包含的属性?其余的只是瞬态属性。

【问题讨论】:

    标签: java hibernate orm entity dao


    【解决方案1】:

    好吧,如果您从不需要它们,请不要映射它们。根据您的架构/意图,当然没有理由映射您不需要的东西。如果您以后确实需要它们,请添加它们。根据使用情况,您可能希望为 HQL/JPA QL/Criteria 查询添加它们,或者您可能只想在 SQL 中执行查询。最终,您可能需要重新设计或重新考虑缓存性能,但这就是事情的发展方向。只要确保你有一个体面的测试套件。

    没什么大不了的。 ::耸肩::

    一般来说,稍后添加内容很容易。删除也不错。移动/拆分是困难的(例如,将 NAME 拆分为 FIRST 和 LAST)。

    【讨论】:

      【解决方案2】:

      OOP 没有被破坏。关系数据库没有损坏。两种表示数据的方式之间只是阻抗不匹配。

      覆盖多个表的复杂查询需要复杂的映射,Hibernate 会在后台执行必要的连接。

      【讨论】:

        【解决方案3】:

        您可能不会使用它们来获取照片,但您肯定会在查询中使用它们。例如:

        select user.id, user.name, count(friend.id)
        from User user left join user.friends friend
        froup by user.id, user.name
        

        为了能够从用户导航到他的朋友,您需要使用 OneToMany 注释注释的 friends 集合。

        您可以将此集合设为私有,并避免让任何访问者访问此集合。

        请注意,在您的示例中,用户可能拥有太多照片和朋友,无法使收藏集变得有用,但情况并非总是如此。我目前正在处理的应用程序中有很多 toMany 关联,其中包含 0 到 100 个元素。 0 到 10 非常频繁。

        另外,不要忘记,在您的“通常”用例(包括列出一些用户的照片)旁边,您肯定会有“不寻常”用例,您必须在其中批量应用更改用户的所有照片,或类似的东西。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2018-02-23
          • 2021-10-04
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2017-07-16
          • 1970-01-01
          相关资源
          最近更新 更多