Да, конечно, но остальные коммиты будут в ветке. В network будут отдельно коммиты сделанные в мастер и отдельно коммиты сделанные в ветку + мердж коммит.
А для того что бы по номеру коммита из истории в мастере определить из какой ветки он в нее пришел достаточно посмотреть вверх по истории до ближайшего мержда. Ну и конечно ветку нужно называть по номеру тикета.
Если стоит задача просто упорядочить код репозитория, разделить запросы фронта, бэка и т. п. для более удобной работы с ними, то можно просто использовать трейты.
@Fesor уже предложил решение получше. Использовать спецификацию из DDD (пример)
В общем и в целом, выделение кода приложения в отдельные бандлы имеет смысл только если они не зависят друг от друга
Естественно речь шла о полном разделении и минимизации связей между бандлами. В одном из докладов, Олег Зинченко говорил о том что разделение приложения на несколько бандлов, керналов и фронт контроллеров позволит легко управлять отдельно каждой частью проекта независимо. Так же должна повысится читаемость и организованность кода по сравнению хранением всего проекта в одном бандле. И за счет разделения мы значительно уменьшим количество сервисов в каждой части приложения что тоже приведет к своим плюсам.
Вы вселяетесь в отель, а там говно по стенам, но жить-то можно, все ж живут
Скорее так:
Я видел эти отели. Там грязно. Я видел волос на полу и складку на постеле. В ванной небыло одноразовых тапочек. А полотенце не было сложено в виде лебедей. А ещё халат висел не на вешелке. А ночью я видел свет из коридора в щель под дверью.
Отели это зло. Я лучшие по своему. В картонной коробке на улице. Она продувается, в ней холодно, жёстко и она намокает и разваливается от дождя. Но это моя коробка. Я сам её собирал. Я сам заклеивал все дыры скотчем. Я знаю её как облупленную. А в этих ваших отелях даже щель под дверью закрыть нечем.
Шаблон спецификация не регламентирует то как вы выборки делаете. И я не про Criteria доктриновскую. У меня спецификации работают с query builder-ом.
Я думал вы про шаблон проектирования, а тут выходит всё ещё хитрее. Не поделитесь примерчиком?
Мы сделали отдельно отдел фронтэндщиков что бы похапэшники не лезли во фронтэнд. И я могу сказать что это весьма профитно.
Ну дык. Конечно. Я версткой занимаюсь только на своём проекте. На работе уже несколько лет во фронтенд залезаю только чтоб что-то быстро поправить когда верстальщики заняты или в админке нужно какую-то плюшку прикрутить побыстрому.
А что есть "оптимально"? Схема там генерится так как описано, это все же не полностью все на магии.
О, там много чего:
индексы нужно описывать в аннотациях. Мелочь, а не приятно
FOREIGN KEY доктрина не создает или я не нашел как это сделать
Хотябы на уровне таблицы нужно ставить кодировку. Не стоит расчитывать на настройки сервера.
кодировку для полей ставить тоже не очень удобно.
комментарии к полям таблицы и самой таблицы добавляются не очень красиво. В русскоязычных проектах я всегда добавляю комментарии, чтоб любой разработчик, не знакомый с проектом, мог по базе понять как всё устроено.
для интов тоже нужно указывать длинну. Если мы точно знаем что в конкретном случае число не будет больше 200, то нет необходимости использовать INT, тут больше подойдет TINYINT(2) UNSIGNED.
если в базе используется TINYINT (2) доктрина всё равно преобразует его в boolean при генерации маппинга.
для представления boolean в бд доктрина использует антипаттерн TINYINT(1) со значениями 1 и 0. Во первых в MySQL есть тип данных BOOLEAN который экономичней, но имеет значения TRUE и NULL, что не совсем логично(давно не заглядывал в доку) сейчас этого типа уже нет, а BOOL это синоним к TINYINT. В TINYINT(1) в действительности можно записать не только 0 и 1, а можно записать числа 0-9 и NULL, а если не стоит UNSIGNED то и отрицательные числа замечательно записываются. Это звучит смешно, но мне один раз достался проект в котором у пользователей в поле gender были значения 0, 1, 2, 3, 4 и NULL. Назначение некоторых значений не знали даже самые старые члены команды. И для каждого пола 10к+ пользователей. Поэтому я предпочитаю использовать тип ENUM. Он занимает столько же места что и TINYINT, но чётко ограничивает набор доступных значений и делает их более информативными. Согласитесь, status 0/1 выглядит менее информативно чем status enabled/disabled? И расширять такие статусы проще. Были у меня случаи когда при изменении требований boolean превращался в enum.
Все это можно обойти. Сконфигурировать в аннотациях, скорректировать в DBAL и тд, но на мой взгляд лучше если будет нормальная, легко читаемая бд и не надо лезть в код проекта каждый раз когда что-то не понятно в бд. И имея на руках одну только базу можно легко написать новый проект на другом языке.
мне нравится паттерн спецификация
Согласе. Интересный паттерн. Хотя он решает только треть задач ставящихся перед репозиторием. Он позволяет управлять фильтрами, но запросы это не только выражение where, но и джойны, группировки, хевинги, кастомезированные селекты и т.д. Видимо нужно создавать классы для отдельных запросов, но что тогда делать с внешними зависимостями.
Если это было на тех выходных, то может даже я это и говорил)
Я смотрел доклад Олега Зинченко опубликованнный в 2014 году. На прошлой неделе что-то я таких замечаний не слышал.
У меня бэкэнд это чисто HTTP API, а админки, круды и т.д. у меня сделаны на ангулярах.
Это хорошо когда есть сильные фронтенд программисты. Я таким похвастаться не могу. Сам во фронтенд стараюсь не лезть.
В дрогой статье про неправильный путь в PHP вы писали что сначала создаете объектную структуру в соответствии с бизнес логикой, описваете мапинг и диктрина сама билдит вам схему бд.
Вы не обращали внимание на то что схема генерируемая доктриной сильно не оптимальна?
я уже пробовал "ваш" подход на протяжении 3-х лет и "мой" подход на протяжении последнего года
Не удивлен. Потому я и считаю что каждый должен заниматся своей задачей. Имхо сериализация и десериализация не относятся к задачам модели.
Я допускаю использование бандлов если в будущем есть шанс разделить все на микросервисы
Я скорей имел в виду разделение на окружения и выделение отдельных фронт контроллеров. То есть получаются практически полностью разные приложения в одном проекте. При необходимомти их можно полностью разделить. Это позволяет нам разделить конфигурации окружений, разделить набор сервисов, разделить модели и репозитории.
Пример конкретной проблемы. Сейчас переписываю один проект с 0 и в репозиториях у меня получается каша. Там есть методы которые используются только в админке, есть методы которые есть только в консоли, методы которые используются только на фронте и методы которые используются для мигрирования данных со старого проекта на новый. Всё это разные методы и ни как не пересикаются.
И вот эта каша мне савсем не нравится. Есть у вас какие мысли на этот счёт?
никаких CoreBundle-в
Инфраструктуру выносить в бандлы — очень удобно. Например UploadBundle и т.д.
Полностью согласен. В одном из дакладов на framework day тоже говорили что CoreBundle это зло. Только я предпочитаю компоненты выносить не просто в бандлы, а в отдельные Composer пакеты.
Короч вы предлагаете вместо "давайте разберемся что такое ООП, как проектировать системы, как использовать подходы и инструменты те что надо и там где это надо" фигачить все как тупой CRUD.
Почти. Я "предлагаю" разбиратся в ООП и не использовать CRUD там где это действительно необходимо. На мой взгляд это действительно необходимо на фронте. В админке же работает ограниченный набор людей которые сидят рядом со мной и которым я лично могу надавать по шапке в случае чего.
Учитывая мощь Sonata, грешно не воспользоваться ею хотябы на первых этапах запуска проекта.
@Fesor Спасибо за конкретный пример. Я уже в общем понял что вы имели в виду, но за еще один пример спасибо. Я уже понял что обще признанные решения вы считаете недопустимыми.
Чем-то вы мне напоминаете нашего общего знакомого G-M-A-X. Вместо того чтоб использовать готовое решение делаем свое. Согласен, если мы разрабатываем ПО опираясь на парадигму Domain Driven Design, то готовые решения просто невозможно использовать. Я же предпочитаю опираться на Data Driven Design чтоб не усложнять себе жизнь и повышать уровень реиспользования кода. Да и не было у меня пока еще проектов с супер сложной бизнес логикой.
Сейчас решил углубится в тему DDD и был бы рад обмену опытом. Вы не думали написать статью на тему использования DDD в Symfony?
Размышления на тему
Как на счет сериализации сущностей для всяких API?
В соответствии с форматом определяем формат нормализации объекта
Непосредственно нормализацию наверное выполняем все таки в сервисе, а не в сущности
На каждый формат для сущности я бы делал свой сервис чтоб не захламлять сериалайзер
А вот с денормализацией вопрос (эта задача хоть и не частая, но все равно задача)
Исходя из вашей логики денормализацией должна заниматься сущность.
Условно, пришел запрос от пользователя с id сущности и набором полей.
получаем сущность из бд
передаем сущность и данные в сериалайзер
сериалайзер передает данные в сущность
сущность заполняет свои поля на основе данных
Вроде все норм, если не считать что формат для нормализации мы определяем в одном месте, а формат денормализации используется в другом.
Можно задачу нормализации также возложить на сущность и тогда все будет в одном месте, но тогда в сущности будет куча пар методов нормализации и денормализации для каждого формата и контекста, и смысла в сервисе сериалайзере теряется.
Если мы получаем конкретную сущность то формат будет один, а если мы получаем эту же сущность как связь от другой сущности то формат будет сильно короче и без собственных связей скорей всего.
Получаем минимум 4 дополнительных метода в сущности.
Так же не понятно как мы должны заполнять связи сущности при денормализации. Видимо туда же нужно передавать сериалайзер.
Мысль другая
Как идея. Разбить проект на 4 бандла и 4 окружения:
Frontend — веб часть проекта
Backend — админка
API — внешние сервисы
Core — для общего набора функций (не очень хорошая практика, но иногда иначе никак)
Идея в том чтобы весь набор сущностей сделать индивидуальным для каждого бандла / окружения. Копии сущностей и свой набор независимых репозиториев для каждого окружения. Не все бизнес процессы которые есть в API нудны на фронте, а задачи которые ставятся в админке не должны быть доступны остальным окружениям.
В таком случае фронтенд и api можно писать по DDD, а админку делать с тупым CRUD, сеттерами и на SonataAdminBundle. Это конечно если бизнес логика нам важна именно на внешнем интерфейсе, а не в админке, а так по идее и должно быть ибо админка все таки для администраторов.
Из минусов мы получаем дублирование некоторых функций (решается наследованием или трейтами)
Из плюсов нам не нужно писать админку с нуля под каждый проект отвечающую нашим бизнес задачам.
Интересный у вас взгляд на реиспользование кода и оптимизацию процесса разработки.
Доктрина слишком умная для сонаты — давайте напишем свою доктирину, но попроще.
Соната слишком универсальная для дактрины — давайте напишем свою сонату, но отвечающую нашим требованиям.
Слушайте, а симфони для вас не слишком универчальная? Может стоит написать свой фраймворк? Хотя что-то мне вспоминается что вы так и сделали.
Ладно. Хорошего понемножку. Прошу прощение за разведение холивара и за возможную грубость. Я понял вашу позицию. Я согласен что это интересный и наверное правильный подход. Если у меня будет ну очень много свободного времени, то я обязательно попробую ваш подход. Сейчас у меня даже на свой проект времени нет, а все задачи ставятся со сроком вчера.
Выглядит неплохо, но у этого подхода есть недостатки:
Как я уже говорил, этот подход полностью не совместим с SonataAdminBundle.
Это означает необходимости написания своей админки с нуля.
А это уже повлечет за собой дополнительные расходы ресурсов компании на что будет готова пойти далеко не каждая, даже крупная, компания.
Этот подход не позволяет использовать оригинальные сущности в формах.
Это означает создание новых сущностей, почти полных клонов оригинальной сущности, для использования их в формах и последующей конвертации в оригинальны сущности доктирины.
В этот подход неплохо укладывается Command Bus, но в результате мы плодим пустые сущности, дублирование кода и оверхед.
Отказ от стандартных компонентов усложняет проект и повышает цену сопровождения кода.
На эту тему была хорошая статья на хабре (сейчас не могу найти), чем плоха разработка с нуля и разработка полностью под себя, игнорируя готовые решения.
Но на событие можно делать какие-то дополнительные действия. Например отправить пользователю на email отчет о том что его пароль был изменен. Естественно в письме пароль не указываем, а только уведомляем, что бы пользователь мог оперативно отреагировать на несанкционированную смену пароля в его профиле.
Может я чего-то не понимаю, но вроде говорили про то, что сделать выбрасывания события на $user->setPassword(), обработчик которого будет хэшировать пароль и вызывать $user->setHashedPassowrd();
Это конечно вариант, но в этом случае метод setPassword() должен в зависимостях иметь Event Dispatcher. И это действительно получится ненужный оверхед. Я же имел в виду выбрасывание событие из контроллера.
$this->dispatcher->dispatch(
StoreUserEvents::CHANGE_PASSWORD,
new ChangeUserPassword($user, $password)
);
а в обработчике уже хешировать
public function onChangeUserPassword(ChangeUserPassword $event)
{
$event->getUser()->setHashedPassowrd($this->hasher->hash($event->getPassword());
}
Да сущности захешированый пароль тоже не нужен. Ей нужен пароль. А хешировать этот самый пароль нужно кому-то другому. Например Symfony Security
Как минимум зачем вводить оверхид да ещё с циклическими зависимостями, если можно сделать простой вызов функции?
Ну во первых потому что это уже реализовано в Symfony, во вторых для создания тонких контроллеров, ну и в третьих можно сразу в бд писать и хешировать пароль средствами бд. Тогда оверхед будет еще меньше.
А ещё события могут логироваться, а там plaintext.
Пример можно? А то, кажется, про разные вещи говорим
Телепрограмма. Если нам нужно вытащить следующее/предыдущее событие то можно использовать sql запрос с выборкой по дате, а можно использовать напрямую связанное следующее/предыдущее событие. Второй вариант будет быстрее при выборке
Да, конечно, но остальные коммиты будут в ветке. В network будут отдельно коммиты сделанные в мастер и отдельно коммиты сделанные в ветку + мердж коммит.
А для того что бы по номеру коммита из истории в мастере определить из какой ветки он в нее пришел достаточно посмотреть вверх по истории до ближайшего мержда. Ну и конечно ветку нужно называть по номеру тикета.
https://habrahabr.ru/post/106912/
А чем не устроил TortoiseGit? TortoiseSvn в туже степь. Можно еще gui из PhpStorm, но я лично gui не использую. Мне консоль удобнее.
В гите можно мерждить ветку с флагом
--no-ffи тогда в network будет видно откуда коммиты пришли.@Fesor уже предложил решение получше. Использовать спецификацию из DDD (пример)
Естественно речь шла о полном разделении и минимизации связей между бандлами. В одном из докладов, Олег Зинченко говорил о том что разделение приложения на несколько бандлов, керналов и фронт контроллеров позволит легко управлять отдельно каждой частью проекта независимо. Так же должна повысится читаемость и организованность кода по сравнению хранением всего проекта в одном бандле. И за счет разделения мы значительно уменьшим количество сервисов в каждой части приложения что тоже приведет к своим плюсам.
Скорее так:
Я видел эти отели. Там грязно. Я видел волос на полу и складку на постеле. В ванной небыло одноразовых тапочек. А полотенце не было сложено в виде лебедей. А ещё халат висел не на вешелке. А ночью я видел свет из коридора в щель под дверью.
Отели это зло. Я лучшие по своему. В картонной коробке на улице. Она продувается, в ней холодно, жёстко и она намокает и разваливается от дождя. Но это моя коробка. Я сам её собирал. Я сам заклеивал все дыры скотчем. Я знаю её как облупленную. А в этих ваших отелях даже щель под дверью закрыть нечем.
ну вот. пиарились, пиарились и тут выясняется что я не я, корова не моя.
это называется аудит безопасности и стоит он очень приличных денег
да, до вас походу вообще ничего не доходит.
лишь бы ляпнуть какую фигню без хоть малейшего понимания вопроса
и пишете еще большую помойку, но свою. родная помойка не пахнет
Да выложите вы уже ваш говнокод. Мы найдем в нем 100500 дыр и багов и тема "фраймворк vs самопис" будет закрыта.
PS: и не надо повторяться что вы не готовы делиться своим говном
Библиотеку видел, но дальше readme не ушёл и про QueryModifier не прочитал. Спасибо
Я думал вы про шаблон проектирования, а тут выходит всё ещё хитрее. Не поделитесь примерчиком?
Ну дык. Конечно. Я версткой занимаюсь только на своём проекте. На работе уже несколько лет во фронтенд залезаю только чтоб что-то быстро поправить когда верстальщики заняты или в админке нужно какую-то плюшку прикрутить побыстрому.
О, там много чего:
Во первых в MySQL есть тип данных BOOLEAN который экономичней, но имеет значения TRUE и NULL, что не совсем логично(давно не заглядывал в доку) сейчас этого типа уже нет, а BOOL это синоним к TINYINT. В TINYINT(1) в действительности можно записать не только 0 и 1, а можно записать числа 0-9 и NULL, а если не стоит UNSIGNED то и отрицательные числа замечательно записываются. Это звучит смешно, но мне один раз достался проект в котором у пользователей в поле gender были значения 0, 1, 2, 3, 4 и NULL. Назначение некоторых значений не знали даже самые старые члены команды. И для каждого пола 10к+ пользователей. Поэтому я предпочитаю использовать тип ENUM. Он занимает столько же места что и TINYINT, но чётко ограничивает набор доступных значений и делает их более информативными. Согласитесь, status 0/1 выглядит менее информативно чем status enabled/disabled? И расширять такие статусы проще. Были у меня случаи когда при изменении требований boolean превращался в enum.Все это можно обойти. Сконфигурировать в аннотациях, скорректировать в DBAL и тд, но на мой взгляд лучше если будет нормальная, легко читаемая бд и не надо лезть в код проекта каждый раз когда что-то не понятно в бд. И имея на руках одну только базу можно легко написать новый проект на другом языке.
Согласе. Интересный паттерн. Хотя он решает только треть задач ставящихся перед репозиторием. Он позволяет управлять фильтрами, но запросы это не только выражение where, но и джойны, группировки, хевинги, кастомезированные селекты и т.д. Видимо нужно создавать классы для отдельных запросов, но что тогда делать с внешними зависимостями.
Я смотрел доклад Олега Зинченко опубликованнный в 2014 году. На прошлой неделе что-то я таких замечаний не слышал.
Это хорошо когда есть сильные фронтенд программисты. Я таким похвастаться не могу. Сам во фронтенд стараюсь не лезть.
В дрогой статье про неправильный путь в PHP вы писали что сначала создаете объектную структуру в соответствии с бизнес логикой, описваете мапинг и диктрина сама билдит вам схему бд.
Вы не обращали внимание на то что схема генерируемая доктриной сильно не оптимальна?
Не удивлен. Потому я и считаю что каждый должен заниматся своей задачей. Имхо сериализация и десериализация не относятся к задачам модели.
Я скорей имел в виду разделение на окружения и выделение отдельных фронт контроллеров. То есть получаются практически полностью разные приложения в одном проекте. При необходимомти их можно полностью разделить. Это позволяет нам разделить конфигурации окружений, разделить набор сервисов, разделить модели и репозитории.
Пример конкретной проблемы. Сейчас переписываю один проект с 0 и в репозиториях у меня получается каша. Там есть методы которые используются только в админке, есть методы которые есть только в консоли, методы которые используются только на фронте и методы которые используются для мигрирования данных со старого проекта на новый. Всё это разные методы и ни как не пересикаются.
И вот эта каша мне савсем не нравится. Есть у вас какие мысли на этот счёт?
Полностью согласен. В одном из дакладов на framework day тоже говорили что CoreBundle это зло. Только я предпочитаю компоненты выносить не просто в бандлы, а в отдельные Composer пакеты.
Почти. Я "предлагаю" разбиратся в ООП и не использовать CRUD там где это действительно необходимо. На мой взгляд это действительно необходимо на фронте. В админке же работает ограниченный набор людей которые сидят рядом со мной и которым я лично могу надавать по шапке в случае чего.
Учитывая мощь Sonata, грешно не воспользоваться ею хотябы на первых этапах запуска проекта.
@Fesor Спасибо за конкретный пример. Я уже в общем понял что вы имели в виду, но за еще один пример спасибо. Я уже понял что обще признанные решения вы считаете недопустимыми.
Чем-то вы мне напоминаете нашего общего знакомого G-M-A-X. Вместо того чтоб использовать готовое решение делаем свое. Согласен, если мы разрабатываем ПО опираясь на парадигму Domain Driven Design, то готовые решения просто невозможно использовать. Я же предпочитаю опираться на Data Driven Design чтоб не усложнять себе жизнь и повышать уровень реиспользования кода. Да и не было у меня пока еще проектов с супер сложной бизнес логикой.
Сейчас решил углубится в тему DDD и был бы рад обмену опытом. Вы не думали написать статью на тему использования DDD в Symfony?
Размышления на тему
Как на счет сериализации сущностей для всяких API?
Исходя из вашей логики денормализацией должна заниматься сущность.
Условно, пришел запрос от пользователя с id сущности и набором полей.
Вроде все норм, если не считать что формат для нормализации мы определяем в одном месте, а формат денормализации используется в другом.
Можно задачу нормализации также возложить на сущность и тогда все будет в одном месте, но тогда в сущности будет куча пар методов нормализации и денормализации для каждого формата и контекста, и смысла в сервисе сериалайзере теряется.
Если мы получаем конкретную сущность то формат будет один, а если мы получаем эту же сущность как связь от другой сущности то формат будет сильно короче и без собственных связей скорей всего.
Получаем минимум 4 дополнительных метода в сущности.
Так же не понятно как мы должны заполнять связи сущности при денормализации. Видимо туда же нужно передавать сериалайзер.
Мысль другая
Как идея. Разбить проект на 4 бандла и 4 окружения:
Идея в том чтобы весь набор сущностей сделать индивидуальным для каждого бандла / окружения. Копии сущностей и свой набор независимых репозиториев для каждого окружения. Не все бизнес процессы которые есть в API нудны на фронте, а задачи которые ставятся в админке не должны быть доступны остальным окружениям.
В таком случае фронтенд и api можно писать по DDD, а админку делать с тупым CRUD, сеттерами и на SonataAdminBundle. Это конечно если бизнес логика нам важна именно на внешнем интерфейсе, а не в админке, а так по идее и должно быть ибо админка все таки для администраторов.
Из минусов мы получаем дублирование некоторых функций (решается наследованием или трейтами)
Из плюсов нам не нужно писать админку с нуля под каждый проект отвечающую нашим бизнес задачам.
тут интереса ради заглянул под капот FOSUserBundle
при изменении сущности, по событию от Doctrine, выполняется обновление пароля
https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Doctrine/UserListener.php#L97
при обновлении берется plain password (он не хранится в бд), хешируется и сохраняется как основной пароль через setPassword
https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Model/UserManager.php#L195
как раз примерно такой вариант я и имел в виду, хотя я уже понял что вы не приверженец сеттеров и хеширования пароля вне пользователя
Вклинюсь в обсуждение. На тему index.php, это не что ино как шаблон проектирования Front Controller.
@aktuba советую не увликатся холиваром. Макс не адекватен и осознавать этого не хочет. Не ты первый пытаешся направить его на путь истинный
Интересный у вас взгляд на реиспользование кода и оптимизацию процесса разработки.
Доктрина слишком умная для сонаты — давайте напишем свою доктирину, но попроще.
Соната слишком универсальная для дактрины — давайте напишем свою сонату, но отвечающую нашим требованиям.
Слушайте, а симфони для вас не слишком универчальная? Может стоит написать свой фраймворк? Хотя что-то мне вспоминается что вы так и сделали.
Ладно. Хорошего понемножку. Прошу прощение за разведение холивара и за возможную грубость. Я понял вашу позицию. Я согласен что это интересный и наверное правильный подход. Если у меня будет ну очень много свободного времени, то я обязательно попробую ваш подход. Сейчас у меня даже на свой проект времени нет, а все задачи ставятся со сроком вчера.
Выглядит неплохо, но у этого подхода есть недостатки:
Это означает необходимости написания своей админки с нуля.
А это уже повлечет за собой дополнительные расходы ресурсов компании на что будет готова пойти далеко не каждая, даже крупная, компания.
Это означает создание новых сущностей, почти полных клонов оригинальной сущности, для использования их в формах и последующей конвертации в оригинальны сущности доктирины.
В этот подход неплохо укладывается Command Bus, но в результате мы плодим пустые сущности, дублирование кода и оверхед.
На эту тему была хорошая статья на хабре (сейчас не могу найти), чем плоха разработка с нуля и разработка полностью под себя, игнорируя готовые решения.
можно конечно и в контроллере все сделать
Но на событие можно делать какие-то дополнительные действия. Например отправить пользователю на email отчет о том что его пароль был изменен. Естественно в письме пароль не указываем, а только уведомляем, что бы пользователь мог оперативно отреагировать на несанкционированную смену пароля в его профиле.
Это конечно вариант, но в этом случае метод
setPassword()должен в зависимостях иметь Event Dispatcher. И это действительно получится ненужный оверхед. Я же имел в виду выбрасывание событие из контроллера.а в обработчике уже хешировать
Да сущности захешированый пароль тоже не нужен. Ей нужен пароль. А хешировать этот самый пароль нужно кому-то другому. Например Symfony Security
Ну во первых потому что это уже реализовано в Symfony, во вторых для создания тонких контроллеров, ну и в третьих можно сразу в бд писать и хешировать пароль средствами бд. Тогда оверхед будет еще меньше.
Запросы тоже могут логироваться, а там plaintext.
Телепрограмма. Если нам нужно вытащить следующее/предыдущее событие то можно использовать sql запрос с выборкой по дате, а можно использовать напрямую связанное следующее/предыдущее событие. Второй вариант будет быстрее при выборке