Question

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

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

因为我不打算使用那些......永远。看起来，我需要做一些分页或其他类型的格式化，所以我想我总是会这样做：

photoDAOInstance.find(searchCriteria);

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

Answer 1

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

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

Answer 2

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

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

一般来说，以后添加内容很容易。删除也不错。移动/分割是很难的（例如，将NAME分成FIRST和LAST）。

Answer 3

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

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

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

您可以将此集合设为私有，并且如果您愿意，可以避免使用此集合的任何访问者。

请注意，在您的示例中，用户可能拥有过多的照片和朋友来使该集合变得有用，但实际情况并非总是如此。我正在处理的应用程序中有很多toMany关联，其中包含0到100个元素。 0到10是非常频繁的。

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

具有复杂实体类的重点是什么（在Hibernate意义上）

3 个答案: