在我的系统中，我有一些从概念上继承自 User 的实体。例如，我可以有供应商和普通消费者。我希望扩展用户实体，以便我可以继承所有用户权益，如注册、登录、丢失密码等。
我有几个选择：
1. 使用 Hibernate 继承策略之一 (https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/inheritance.html) 扩展 User 实体，但看起来需要对代码进行大量更改。我还必须确保表格生成也是正确的，并且可以与 liquibase 一起正常工作；
2. 将所有必要的属性添加到用户实体，然后添加供应商和消费者作为角色。这样做我只是觉得不舒服，因为用户表不会被规范化；
3.创建从这些实体中的每一个到用户实体的关系，但是在这种情况下，我不清楚如何继承用户管理的好处。
有没有人做过类似的事情，以便对此有所了解？
提前致谢。
【问题讨论】：
标签： jhipster
我宁愿使用组合而不是继承。所以基本上，你会让供应商与用户保持一对一的关系。这样，你就让 JHipster User 相关的代码不变。
User management feature 尚未发布，所以让我们关注用户注册，那么用户如何才能成为供应商或客户？他们应该自己选择吗？用户可以同时是消费者和供应商吗？
对我来说，简单的 JHipster CRUD 屏幕是不够的，您必须准备好构建自己的屏幕以获得更好的用户体验。所以，我宁愿专注于拥有强大的数据模型和 REST API。
【讨论】：
我找到了第二种方法的方法。
我将每个子类（在我的示例中为供应商和客户）的所有属性添加到表用户 (JHI_USER) 和类型属性中，以便我可以知道我正在处理的用户类型。我还在 User 类中添加了它们各自的属性并更新了相关的类，如 UserService、UserRepository、测试类等。我也使用了角色的概念，但只是为网站的每个部分提供权限。
之后，我为每个用户类型创建了一个 AngularJS 状态，并传递了它的类型（有点像鉴别器）。例如，我创建了一个名为 /registerSupply 的状态，传递了它的 type = 'S'。然后，我编辑了原始注册页面以添加所有其他供应商和客户属性，根据用户类型将它们过滤掉，就是这样。
正如我所说，使用这种方法我感觉不舒服，但最后，它基本上是 Hibernate (https://docs.jboss.org/ejb3/app-server/tutorial/singleinheritance/single.html) 建议的策略之一，这让我感觉好一点。
【讨论】：
this issue 中解释的首选方式是使用 Git。只需手动添加代码，并在从 JDL 重新生成代码时使用 git merge。
使用组合会创建一个对大量使用的实体有性能影响的 JOIN。实体继承有效，但 JPA 很难，生成的代码更难。
如果我必须在组合和继承之间进行选择，我更喜欢在应用程序增长时使用缓存组合。
【讨论】：