2015-05-22 2 views
1

Моя цель - наследовать уже унаследованную таблицу с помощью доктрины. У меня есть абстрактный класс пользователей ...Symfony2 наследует от унаследованной таблицы

<?php 
namespace UserBundle\Entity; 

use Doctrine\ORM\Mapping as ORM; 
use FOS\UserBundle\Model\User as BaseUser; 

/** 
* @ORM\Entity 
* @ORM\InheritanceType("JOINED") 
* @ORM\DiscriminatorColumn(name="type", type="string") 
* @ORM\DiscriminatorMap({"student" = "Student", "employee" = "Employee", "customer" = "Customer"}) 
*/ 
abstract class User extends BaseUser 
{ 
} 

... и различные подклассы (ученик, клиент, сотрудник). Нравится этот:

<?php 
namespace UserBundle\Entity; 

use Doctrine\ORM\Mapping as ORM; 

/** 
* UserBundle\Entity\Student 
* 
* @ORM\Entity 
*/ 
class Student extends User 
{ 
} 

Внутри этой установки все работает нормально. Теперь другие пакеты, рассматриваемые как отдельные модули, должны содержать столбцы из подклассов. Поэтому мне нравится наследовать от таких классов, как ученик. Но они не могут быть абстрактными, потому что они используются базовой системой.

Можно ли разрешить это с наследованием таблицы классов доктрины? А если нет, какое решение вы бы порекомендовали?

ответ

2

К сожалению, в доктрине невозможно иметь более одного уровня наследования.

Возможно, вы захотите пересмотреть свой дизайн, поскольку такая сильная потребность в наследовании может стать признаком тревожных новостей.

Давайте студент, например: По declearing этого заявления:

class Student extends User 

неявно говоря, что все мой ученик также пользователи. Это может звучать правдоподобно, но рассмотрим сценарий пользователя, который является учеником и учителем (например, ассистентом университета).

Возможно, может быть какое-то профилирование пользователей, которые связывают пользователя с другим объектом. Некоторым пользователям действительно не хватает этого отношения, как в случае системы ботов. В этом случае ваш узел/модуль может объявить сущность и связь с пользователем (действующий как мост), который может дополнительно квалифицировать вашего пользователя.

Я не хочу разрушать вашу фактическую структуру, если вы лучше объясните свои потребности, я могу дать некоторое представление.

Надеюсь, это имеет смысл для вас, С уважением.

+1

Thx для ответа @ francesco-panina. В моем szenario действительно пользователь не мог стать и (учеником, и сотрудником), и для _system bots_. Я использую интерфейс API API ... они независимы от любого пользователя (кроме ассоциированных владельцев). Мое окончательное решение для окончательного тезиса: я динамически добавляю дискриминатор в зависимости от текущего модуля и объединяю конкретного пользователя модуля вместе с используемым подклассом. Это работает ... уродливо ... как черт ... – binzram

+0

Чтобы быть откровенным в большинстве случаев, я соглашаюсь с реальностью, и реализация, которую я выбираю, является наиболее рентабельной, которая, вдали от чистого и элегантного ... Если это сработает для вас, не стыдно выбирать какое-либо решение, пока это осознанный выбор. удачи! –

Смежные вопросы