а зачем where писать, доктрина все за тебя сделает

Можно разделять и обобщать. Как лучше разделять и обобщать зависит от задачи

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

Можно разделять и обобщать. Как лучше разделять и обобщать зависит от задачи

Ну тоесть разделенное обобщить проще, чем разделить обобщенное ;)

у пользователя есть роли, в зависимости от этого их можно по-разному регистрировать и авторизировать

Смотря как оно обобщено )

Я имел ввиду наследование

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

Поэтому лучше композиция по возможности

Ну хорошо. А если сделать сущность юзер с одним полем айди, а остальные наследовать от нее?

Ну хорошо. А если сделать сущность юзер с одним полем айди, а остальные наследовать от нее?

ну мы же не знаем какая задача? плохо если у человека проект достаточно сложный, а он симфони чате такие вопросы задает.. это в любом случае плохо и никак ты не поможешь. мне кажется, тут по дефолту проект из серии бложик или познакомится с симфони.

Ну хорошо. А если сделать сущность юзер с одним полем айди, а остальные наследовать от нее?

Зачем наследовать?)

Чтобы был у всех уникальный айди

Ему пофиг, хоть на фронте генерируй ;)

Тогда можно делать разные сущности и юзать трейты )

Ох...и трейты еще ;)

мне кажется плохо делать как всегда и не задаваться вопросами, а как можно сделать лучше)

сначала надо сделать, чтоб работало. я и не говорю, что вот мой совет в 100 % случае верный. но если не знаешь как сделать, то попробуй и этот вариант, завести будешь проще и быстрее. а что лучше для твоего проекта, кто ж тебе тут скажет?

отсюда и возник вопрос, кто как предпочитает делать

проблем с тем что бы это работало никогда не было, но это не значит что нет лучшего решения)

pubf publishPost(Admin $publisher) Или pubf publishPost(User $publisher){ if ($publisher->isAdmin())

с чего ты взял? может в контексте поста роль юзера не имеет значения

И такие if по всему коду будут ;)

pubf publishPost(Admin $publisher) Или pubf publishPost(User $publisher){ if ($publisher->isAdmin())

работаем с Admin и вытаскиваем $admin->getUser() если нужно

пост тут вообще ни при чем, можешь метод назвать something ;)

короче уже придумали всю бизнес логику.. мда и использование дискриминации тебе вообще никак не мешает писать publishPost(Admin $admin)

Репорты вы как пишете? Через dql?

так еще раз.. я не топлю за совершенство использования дискриминации, я лишь предложил один из вариантов. часто он очень жизнеспособен. а тут сразу начали тапками закидывать ))

кто мы? какие репорты?

Я о том что это костыль ;)

Я о том что это костыль ;)

Зависит от задачи

никто ж не против. но это костыль из коробки. а например, UserInterface избыточен, но что делать. писать свой фреймворк?

Придумай задачу которая оправдает ;) Мне реально интересно

> Ну ты как ты репорты у себя в апликухах делаешь? разные проекты разные ребования, иногда dql, иногда нет

Ну если б писал на sql то понимал бы, что sti будет больше мешать

Ну если б писал на sql то понимал бы, что sti будет больше мешать

в это случае не надо sti использовать, но с чего ты взял что у человека есть такой кейс?

Как он будет мешать?

Придумай задачу которая оправдает ;) Мне реально интересно

Да в том что разные данные в одной реляционной таблице это плохо

данные не разные, а почти одинаковые ))

Да в том что разные данные в одной реляционной таблице это плохо

А если надо будет сделать связь в какой нибудь сущности к любому из юзеров, как это сделать?

Юзер это юзер, админ это админ

Например запись в блоге может менять админ, бородатый админ, манагер, юзер и все остальные

Я б сделал еще одну сущность Author и ликовал бы посты к ней, по логике пост не должен знать ничего о юзере, админе и прочем.

Нету, понятия почти ;) false почти true ;)

А в author как сделаешь эту связь?

ой короч.. надоел. есть задача, ищешь решение. не лучшее с точки зрения теории решение бывает наиболее подходящим. это называется КОМПРОМИС. у меня в проекте частенько дискриминация присутствует и НИКАКИХ проблем. потому что в там где мы ее используем нам не нужны кейсы, проявляющие ее недостатки (raw sql, if/else логика и т.д.)

Вадим говорит, что нет таких случаев, когда есть смысл применять такой вариант

Вадим говорит, что нет таких случаев, когда есть смысл применять такой вариант

Я говорю о том, что нет таких случаев когда не возможно избежать sti

Author::createFromAdmin(Admin $admin) { $author = new static(); $author->name = $admin->name(); return $author; }

а кто спорит? всегда можно сделать как-то по-другому. но зачем? всегда ли это оправдано?

Coupling and cohesion

Author::createFromAdmin(Admin $admin) { $author = new static(); $author->name = $admin->name(); return $author; }

Но так ты уже не сможешь через орм работать со связями

всегда ли это оправдано?