当两个不同的子类扩展相同的实体实例时，原则继承策略

本文介绍了当两个不同的子类扩展相同的实体实例时，原则继承策略的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 我正在开发管理法庭口译服务的申请（使用Doctrine和Zend Framework 2）。有很多人涉及到各种专业角色，因此有一个Person超类和子类。类的层次结构在垂直方面并不复杂 - 一代继承是足够的 - 但横向方面给我的麻烦。 我不认为映射超类单表继承，但是由于子类具有自己的实体关系，因此很快就会变得丑陋，太多东西可以正确地填充到单个表中。 这让我们留下了类表继承，这是一个非常好的适合在大多数方面，但...我将有很多情况下，子类User（用于身份验证）和子类解释器将（或应该）指向在父数据表中的同一行，因为它们在现实中代表同一个人。但是，由于鉴别器列，您必须选择一个或另一个，否则创建两个不同的行持有相同的数据 - 并且规范化警察应该为您提供。 我看过 教义继承，扩展同一超级类的几个实体和 如何更改和实体类型在Doctrine2 CTI继承（除其他外），都没有解决这个问题。 所以，我想知道有没有人有任何建议。谢谢。解决方案听起来你正在管理一堆关于 Person s，它标识世界上的个人。由于系统中只有部分人员是用户，我认为认证，审核日志记录，通知等方面的担忧与 Person class hierarchy。 我建议删除用户 Person 类层次结构。也许将它重命名为帐户，以使其感觉更少。 帐户可以拥有所有者属性，它与 Person 。如果要使用 Person 的电子邮件地址作为身份验证的标识符，那没关系。如果您以后想要添加一个用户名，那将是帐户的属性，因为这只是有意义的上下文。 I am developing an application for managing court interpreter services (using Doctrine and Zend Framework 2). There are a lot of people involved who have various specialized roles, hence a Person superclass, and subclasses. The class hierarchy is not complicated in a vertical sense -- one generation of inheritance is enough -- but the horizontal aspect is giving me trouble.I don't think mapped superclasses fit my case. I also considered single-table inheritance but that would quickly get ugly because the subclasses have their own entity relationships, too much stuff to cram gracefully into a single table.That leaves us with class table inheritance, which is a really nice fit in most respects, but... I will have plenty of cases where the subclass User (for authentication) and the subclass Interpreter will (or should) point to the same row in the parent data table, because they represent one and the same person in reality. But because of the discriminator column you have to choose one or the other, or else create two different rows holding the same data -- and the normalization police should get you for that.I think maybe either the User or the Interpreter entity has to simply have a one-to-one relationship with the Person entity, and deal with that semi-manually. Another option I suppose would be to collapse User into Person -- but that's ugly because a lot of people will not be authenticating and will not have or need a password.I have looked at Doctrine inheritance, several entities extending the same super class and How to change and entity type in Doctrine2 CTI Inheritance (inter alia) and neither one solves this.So, I wonder if anyone has any suggestions. Thanks. 解决方案 It sounds like you're managing a bunch of data about Persons, which identifies individual humans in the world. Since only some subset of the people in the system are Users, I'd argue that concerns about authentication, audit logging, notifications, etc are separate from the concerns of the Person class hierarchy.I'd advise removing User from the Person class hierarchy. Perhaps rename it Account, to make it feel less person-y. An Account can have an owner property, which is a relation to Person. If you want to use the Person's email address as an identifier for authentication, that's fine. If you later wanted to add a username instead, that would be a property of Account, since it's only meaningful in that context. 这篇关于当两个不同的子类扩展相同的实体实例时，原则继承策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！