Раз уж зашел разговор про voters, какой правильный кейс их

использования?
Вот допустим есть command/handler . Задача - редактирование только своей записи. Это выходит надо запись получить в контроллере и пропихнуть ее в voters, прежде чем запускать handler? Не перегружается ли контроллер такими действиями?
Т.е. мы начала получаем запись по ID из репо, а потом ID запускаем в хэндлер и снова тянем из репо. Т.е. делаем это 2 раза. Это хорошо что у нас там IdentityMap, и нет лишних запросов.

а ты в курсе что можно сразу entity закинуть в isGranted/denyAccessblabla и не мучаться

Так я об этои и говорю, что Entity надо достать, и делать это в контроллере.

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

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

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

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

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

Почему?

Я понял вашу мысль, спасибо.

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

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

та я видел и реализации типа Controller:method ( $id, Business $business ) $business->doSomething($id); $business->finishWork(); return $business->result(); что можно понять из этого кода вообще? )

идеальная реализация контроллера

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

а можно бизнес логика не будет знать о существовании репозитория? спасибо

Можно, если ей передавать готовые данные

Если тебе нужно в действии контроллера вытащить данные и прокинуть их в твин ты для этого тоже отдельную сущность будешь делать или в контроллере сделаешь?

ну так мы это и делаем не? Controller:method ( $id, Business $business, Repository $repo ) $business->doSomething($repo->find($id)); $business->finishWork(); return $business->result();

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

Не вижу принципиальной разницы.

Я не совсем вас понимаю. Тут вы тащите репо в бизнес.

нет, тут я тащу Entity внутрь doSomething

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

Можно сделать queryHandler

Зачем? Я думал все это разделение ради принципа единой ответственности и повторного использования. И использования репозиторию в контроллере мне кажется не противоречит.