拥有复杂的实体类有什么意义（在 Hibernate 意义上）

Question

由于经典的 OOP 模型无论如何都被破坏了，尽管 ORM 有很多好处，为什么我需要在我的实体类中注释以下两个示例属性：

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

因为我永远不会使用它们。看起来，我需要进行一些分页或其他类型的格式化，所以我想我总是会选择类似的方法：

photoDAOInstance.find(searchCriteria); 

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

Answer 1

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

没什么大不了的。 ::shrug::

一般来说，以后添加东西很容易。删除也不是坏事。移动/拆分是困难的（例如，将名称拆分为第一个和最后一个）。

Answer 2

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

覆盖多个表的复杂查询需要复杂的映射，而 Hibernate 在幕后执行必要的连接。

Answer 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 是很常见的。

另外，不要忘记，在“常见”用例（包括列出用户的一些照片）旁边，您肯定会有“不寻常”用例，您必须将更改批量应用到所有照片用户的信息，或类似的东西。