两个不同子类扩展同一个实体实例时的教义继承策略

Question

我正在开发一个管理法庭口译服务的应用程序（使用 Doctrine 和 Zend Framework 2）。涉及的人很多，他们具有各种专业角色，因此有一个 Person 超类和子类。类层次在纵向上并不复杂——一代继承就足够了——但是横向方面给我带来了麻烦。

我认为 mapped superclasses 不适合我的情况。我也考虑过single-table inheritance，但这很快就会变得丑陋，因为子类有自己的实体关系，太多东西不能优雅地塞进一个表中。

这给我们留下了class table inheritance，这在大多数方面都非常合适，但是......我将有很多情况，子类 User（用于身份验证）和子类 Interpreter 将（或应该）指向父数据表中的同一行，因为它们代表现实中的同一个人。但是由于有鉴别器列，您必须选择一个或另一个，否则会创建两个不同的行来保存相同的数据——规范化警察应该会为您服务。

我认为用户或解释器实体可能必须简单地与 Person 实体建立一对一的关系，并以半手动方式处理。我认为另一种选择是将 User 折叠成 Person ——但这很丑，因为很多人不会进行身份验证，也不会拥有或不需要密码。 我看过 Doctrine inheritance, several entities extending the same super class 和 How to change and entity type in Doctrine2 CTI Inheritance（除其他外）没有人解决这个问题。

所以，我想知道是否有人有任何建议。谢谢。

Answer 1

听起来您正在管理大量关于 Persons 的数据，这些数据可以识别世界上的个人。由于系统中只有一部分人是Users，我认为对身份验证、审计日志记录、通知等的关注与Person 类层次结构的关注是分开的。

我建议从 Person 类层次结构中删除 User。也许将其重命名为Account，让它感觉不那么人性化。一个Account 可以有一个owner 属性，它是与Person 的关系。如果您想使用Person 的电子邮件地址作为身份验证的标识符，那很好。如果您稍后想添加 username，那将是 Account 的属性，因为它仅在该上下文中有意义。

Answer 2

不确定底层代码（不是 ZF 开发人员），但我认为您混淆了行为和数据。

要使身份验证正常工作，您实际上不需要继承。刚刚发现您在接口依赖项之上编写代码。

为了使用户能够进行身份验证（而普通人不能） - 使用继承，或者像@timdev 建议的那样，使用关系。在 symfony 世界里我最好写这样的东西

class User extends Person implement UserInterface {
  //... implementation
}

class Person {
  //...
}

之后，您可以确定，您拥有UserInterface，尤其是任何服务和身份验证。

如果您必须动态切换 User 实体的底层类（即您有 Author extends Person 并希望允许某些作者登录），我认为组合是唯一合适的解决方案。拆分逻辑，拆分实体，拆分数据。开心点。