Попахивает говнокодом.


_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Не удивлен. Этот запах тебе очень знаком

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

А я и не об этом, ты дурачек что-ли? У меня вопросы к тому как ты используешь контейнер. Проблема именно вот в этом трейте и что в нём, в том как это написано и используется.

Ты просто открываешь ящик пандоры при той архитектуре приложения, которую ты пытаешься использовать. Если я правильно все понял, у тебя вообще должен на каждый контроллер быть своя карта зависимостей и в каждой карте должны быть сущности только для этой точки входа. А сейчас ты тупо намешал все в одну кучу, потому что DRY у тебя под коркой мозга, а та архитектура, которую ты выбрал немножко насилует концепцию DRY.

Проблема пока еще не видна, но такой подход приведет что ты начнешь настраивать контейнер императивно, а как по мне это жопа.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Совершенно неправильно понял. Зачем на каждый контроллер то? Там есть общий, FrontController, от которого наследуются остальные.

Обычно при разделении слоев в контроллерах делают так:

   $dto = (new CommandBus)->execute(new CatalogueReadCommand($this->request));

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

    $dto = $this->commandBus->execute('Catalogue'));

Вот и все. Никакой разницы нет, только упростился код. Чего ты пытаешься тут углядеть криминального, не пойму. Просто опять не разобрался.

Плюсы такого подхода:
1. Контейнер не идет ниже точки сборки.
2. В командную шину не приходит ничего лишнего, только то, что зарегистрировано в локаторе. Причем это все отмечено интерфейсами.
3. Командная шина спускается в виде прокси (ленивая загрузка). Если в каком то контроллере она не нужна, ну и пес с ней.
4. Писать код намного проще, все централизовано.

Ну и тд, тп, пр. пр.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

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

Учи матчасть, еще раз говорю. А то ты сам на дурачка похож с такими заявками.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

То есть ты в контейнер собираешься инкапсулировать фабрики предметной области? Я правильно понимаю?

А я доказывал обратное?

Сущности это не Entity, а объекты которые настроил твой контейнер. Я не знаю как это по другому коротко назвать. Ты же мог был понять, я вроде на DDD контекст не переходил.

С какими? Ты сам с собой споришь в основном. Я тебе о контейнере говорю и о том к чему приведет такое его использование.

Еще бы он шел, я бы тут тебя какашками закидал бы.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

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

Я прекрасно понял, но они там не нужны почти. Там нужны только глобальные общие сервисы, а их не так много. Все остальное должно быть внутри домена. Слоистая архитектура на то и слоистая, что слои не зависят друг от друга. А если объекты для домена пихать в инфраструктурный контейнер, ничего хорошего не выйдет.

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

Ну вот. А твой ходит)))
Лови какашку:


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

За что, там же нет контейнера Сам посмотри

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Ах ты хитрая ты жопа!

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.