1) роутер хранит коллекцию маршрутов (массив если хотите). То есть да. в отдельном приватном поле. Далее уже есть куча вариантов. В самом простом у нас будет метод "setRules" в который мы передаем массив. В самом сложном у ровтера будет еще лоадер правил с возможностью использовать несколько реализаций (ArrayRulesLoader, PhpRulesLoader, YamlRulesLoader и т.д.) Но пока можно не замораичваться. Сейчас надо замарачиваться о формате описания правил.
2) запускать нужный метод контроллера должен не роутер. Он должен сказать "какой маршрут в списке победил", а в маршрут мы уже закладываем информацию о том какой контроллер запускать. Запускать же его будет какая-то отдельная штука которая о роутере ничего не знает.
3) Безопасность тут не причем вообще. Туть в том что бы добиться поддерживаемого кода с низкой связанностью (минимум зависимостей) и высоким зацеплением (все вещи которыми занимается роутер связаны только с маршрутизацией, делаем что-то одно и делаем это хорошо).
Мои рекомендации - посмотрите как это делают другие люди. Пример - библиотека FastRoute. Она собственно написана была как пособие "как писать роутеры".
Андрей: нет, оба варианта не верны. Они нарушают принцип единой ответственности. Вместо того что бы выдать на основе URI маршрут они там еще что-то знают о структуре нашего приложения и еще и умеют это дело вызывать.
leistolz: там 5 строчек кода должно быть. Ну и повторюсь - все будет хорошо только в php7 ибо в php5 придется устанавливать свои обработчики ошибок. В семерке же только исключения.
Поясню еще раз. Контейнер зависимостей - это сервис локатор. Использование сервис локатора - антипаттерн. То есть достаточно не внедрять контейнер в качестве зависимости и все будет хорошо. И будет у нас Dependency Injection.
Сергей Неважнов: ну и важно понимать что сервис локатор признан антипаттерном, так как доступ ко всем зависимостям есть у всех. Мир выбирает иньекцию зависимостей. По сути отличие в том, что сервисы не имеют доступа к контейнеру а лишь получают зависимости откуда-то "сверху". А сам сервис локатор (контейнер) остается снаружи системы.
Денис Загаевский да просто туплю под конец недели. Мне просто смутила фраза "достаточно абстрактный класс". То есть помимо того что на пустом месте у нас не должно возникать подтипов (полиморфизм подтипов же, нам должно быть плевать на реализацию) если они плодятся, нужно что бы они выполняли одну и ту же функцию просто по разному, не нарушая LSP.
Без детализации вопроса мой комментарий на самом деле слегка бессмысленный.
freelancer007: используйте password_api а не просто bcrypt. Он вам и соль сгенерит, и если на замену bcrypt придет более надежный алгоритм - перехэширует вам все... словом... используйте.
Алексей Скобкин: ну тот же vich uploader bundle который предоставляет нам сущности файлов или же как-то влияет на сущности (там есть волшебные штуки на хуках доктрины). Мои сущности не должны зависеть от каких-либо библиотек (в разумной степени конечно), это должен быть plain php, никакой магии и никаких хуков.
Справедливости ради до версии 2.5 с доктриной работать подругому в принципе было тяжко
Алексей Скобкин: есть термиин "сущность" (в терминах доктрины это тоже сущность), это какой-то объект который имеет идентичность (айдишку), и который можно по идентификатору сравнивать с другими объектами. Сам же он состоит из примитивов и/или объектов-значений. Последние - это обычно имутабельные объекты, которые нужно сравнивать по их значению (например объекты равные если значения всех их полей равны). В терминах доктрины объекты-значения - это embeddables или встраевыемые объекты. Доктрина поддерживает их с версии 2.5. Они позволяют делат грамотно декомпозицию и делать волшебные штуки вроде объявить один раз объект и использовать его как обычное значение в куче сущностей.
Николай: я предпочитаю минимизировать различия между окружениями. На самом деле я очень долго думал на эту тему, даже пробовал работать так как вы предлагаете но в итоге плюнул.
Николай: сборка, работа с зависимостями и т.д. это не часть дистрибьюции билдов. В болде уже все должно быть собрано, скачено и поставлено. Можно сказать статически слинковано.
Что до "накатки миграций" из отдельного контейнера - просто это сложнее. Процесс деплоймента усложняется с такого:
1) роутер хранит коллекцию маршрутов (массив если хотите). То есть да. в отдельном приватном поле. Далее уже есть куча вариантов. В самом простом у нас будет метод "setRules" в который мы передаем массив. В самом сложном у ровтера будет еще лоадер правил с возможностью использовать несколько реализаций (ArrayRulesLoader, PhpRulesLoader, YamlRulesLoader и т.д.) Но пока можно не замораичваться. Сейчас надо замарачиваться о формате описания правил.
2) запускать нужный метод контроллера должен не роутер. Он должен сказать "какой маршрут в списке победил", а в маршрут мы уже закладываем информацию о том какой контроллер запускать. Запускать же его будет какая-то отдельная штука которая о роутере ничего не знает.
3) Безопасность тут не причем вообще. Туть в том что бы добиться поддерживаемого кода с низкой связанностью (минимум зависимостей) и высоким зацеплением (все вещи которыми занимается роутер связаны только с маршрутизацией, делаем что-то одно и делаем это хорошо).
Мои рекомендации - посмотрите как это делают другие люди. Пример - библиотека FastRoute. Она собственно написана была как пособие "как писать роутеры".
nikic.github.io/2014/02/18/Fast-request-routing-us...