Как спроектировать роутер?

Question

[fasewyby]

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

Или я не правильно делаю, что в контруктор контроллера передаю зависимости?

Comments

[Ипатьев]

Правильно.
А для вызова контроллеров служит специальный Контейнер внедрения зависимостей. Который создает (или переиспользует) нужные зависимости, и передает их в создаваемый контроллер.

А вот как он узнает, какие именно нужны зависимости - это самый интересный вопрос :)

[Ипатьев]

Виктор Кожухарь вас куда-то не туда унесло. Сначала вы зачем-то пишете, что "ответ кроется в использовании интерфейса", при том что интерфейсы вообще никак не отвечают на вопрос "как внедрять зависимости".

А потом придумали наивное решение создавать экземпляры ВСЕХ контроллеров при каждом запросе. То есть, вместо автоматизации, про которую спрашивал автор, вы предлагаете ему написать вручную код создания каждого используемого в приложении сервиса.
Причём глупость этого решения (изначально неприемлемого из-за чудовищного перерасхода ресурсов) очень быстро выходит из-под контроля, увеличиваясь как снежный ком.
Вы не подумали о том, что зависимости плодятся в геометрической прогрессии. Это только в фантазиях можно сделать new Model1(). И если бы так можно было, то проще было бы это делать в контроллере. Но в реальности модели нужен класс для выполнения запросов. Классу для выполнения запросов нужен класс с соединением к БД. Классу с соединением к БД нужен конфиг. Плюс всем нужны в разных комбинациях конфиг, логгер, мейлер, различные хелперы и куча всего.

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

[Виктор Кожухарь]

Ипатьев, Этот "клубок зависимостей" не так уж страшен, как его малюют)
И простая инициализация всего по порядку гораздо проще в плане отладки, чем дебажить самописный DI контейнер.
А ежели не хочется всё инициализировать при каждом запросе, то тут без кодогенерации либо какого-то там RoadRunner не обойдешься. Тогда уж проще фреймворк взять...

[Ипатьев]

Виктор Кожухарь, вот опять вас шатает по крайностям. Никакая "кодогенерация" и "RoadRunner" ту не нужны.
Вы бы лучше ознакомились с тем, как работает роутер в связке с контейнером. Там нет ничего сложного.
Он просто создаёт экземпляр контроллера, точно так же, как создаёт зависимости для него.

А ещё лучше - попробовали бы написать реальный проект на основе своей "иллюстрации". С вас быстро слетит это шапкозакидательство.

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

[fasewyby]

Ипатьев, контенер есть, чтобы все модели и виды и все остальное связать с контроллерами заняло строк 70 наверно. Ручное связывание, вроде так называется. Ну и в сам роутер передается этот контейнер. С автовайрингом не получится, потому что некоторые классы принимают скалярные типы.

Есть мнение, что контейнер нужен для хранения общих объектов для всего приложения, соединение с базой и т.п. Вот и задумался как сделать без пихания контроллеров в контейнер.

[Ипатьев]

Скалярные типы можно передавать аннотациями. Ну или конфигом, как в старой Симфони.
Ну или ручное связывание
А почему не хочется контроллер в контейнер пихать? В любом случае других вариантов нет - созданием объектов с учетом их зависимостей занимается только контейнер.

[fasewyby]

Ипатьев, спасибо, аннотациями все разрулилось :)