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

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

Вопрос в том, почему мы в контроллере достаем объект бизнес логики, а то и не один, так как ACL(layer) может быть сложным.  Почему в контроллере вообще используется репо.  
В общем вопрос в хорошей практике, а не в документации.

Всем привет. Немного не по симфони, но попробую попросить помощи.
подскажите по событиям, которые генерирует сущность во время своей жизни. Сейчас у нас сделано через трейты+интерфейсы, типа $this->notify(new ShitHappens($this)) и потом postFlush события берутся через $еntity->publishEvents() и бросаются в диспатчер.
Есть ощущение, что уйти от трейтов и хранения событий в сущности было бы правильно. но возникает вопрос - как генерировать и отдавать в мир события?
Для их генерации нужно, чтоб "генерилка" их сторедж событий были либо внутри обьекта, либо приходили снаружи.
Если внутри - трейты, наследование, инжект, создание. Трейты дичь, наследование сущностей от BaseEntity - тоже, инжект - непонятно кем, как и когда. Создание какого-то eventEmiter'а внутри конструктора? Вызов статического метода EventService::foo(new Event)? Но тогда нужно как-то привязывать событие к конкретной сущности.
А если сторадж приходит снаружи, то добавление зависимостей к каждой операции, которая приводит к событиям (включая конструкторы) - тоже дичь.
Как быть, куда бежать?
Или я осел, зря парюсь и трейты норм ход в таком раскладе?

имхо, трейты норм

Ну чот кажется, что таскать с собой все события, которые уже совершились и которые ей уже не нужны - не входит в обязанности сущности

Вопрос в том, почему мы в контроллере достаем объект бизнес логики, а то и не один, так как ACL(layer) может быть сложным.  Почему в контроллере вообще используется репо.  
В общем вопрос в хорошей практике, а не в документации.

А в чем проблема в контроллере репу использовать?

Всем привет. Немного не по симфони, но попробую попросить помощи.
подскажите по событиям, которые генерирует сущность во время своей жизни. Сейчас у нас сделано через трейты+интерфейсы, типа $this->notify(new ShitHappens($this)) и потом postFlush события берутся через $еntity->publishEvents() и бросаются в диспатчер.
Есть ощущение, что уйти от трейтов и хранения событий в сущности было бы правильно. но возникает вопрос - как генерировать и отдавать в мир события?
Для их генерации нужно, чтоб "генерилка" их сторедж событий были либо внутри обьекта, либо приходили снаружи.
Если внутри - трейты, наследование, инжект, создание. Трейты дичь, наследование сущностей от BaseEntity - тоже, инжект - непонятно кем, как и когда. Создание какого-то eventEmiter'а внутри конструктора? Вызов статического метода EventService::foo(new Event)? Но тогда нужно как-то привязывать событие к конкретной сущности.
А если сторадж приходит снаружи, то добавление зависимостей к каждой операции, которая приводит к событиям (включая конструкторы) - тоже дичь.
Как быть, куда бежать?
Или я осел, зря парюсь и трейты норм ход в таком раскладе?

Мне кажется это немного ломает слои.

а что хотели от точки входа в приложение?
или хочется размазать бизнес логику по разным местам - типа где то "до" достать сущность, где то "до" проверить права?
а что тогда останется в самом контроллере?

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

сложная логика acl - ну так прекрасно, пиши в вотерах её, туда же получи нужные зависимости если они требуются

Почему?

Потому что мы в слое который отвечает за request/responce лезем в базу данных и управляем сущностями

Явно передать параметром в методах?

Потому что мы в слое который отвечает за request/responce лезем в базу данных и управляем сущностями

та я видел и реализации типа
Controller:method ( $id, Business $business )
$business->doSomething($id);
$business->finishWork();
return $business->result();

что можно понять из этого кода вообще? )

Мы не лезет в базу. Мы обращаемся к репозиторию.

мы к репо обычно лезем из бизнеса, а тут из контроллера.