При использовании инъекции зависимостей для обработчиков баз данных и т. Д. Вместо singleton – где лучше всего хранить конфиги. Идентификатор пользователя и т. Д. Храните внутри класса, используйте класс контейнера или используйте класс статических конфигураций или используйте файл?
Обычно я держу их в файле за пределами веб-сайта.
Внешний файл конфигурации, который возвращает массив, является быстрым решением:
config.php:
<?php return array( 'database'=> array( 'host'=> 'localhost', 'dbname'=> 'name_of_db', 'username'=> 'myusername', 'password'=> 'mypassword', ), ); test.php:
<?php $config = include('config.php'); mysql_connect($config['database']['host'], $config['database']['username'], $config['database']['password']); ....
В идеале сохраните файл конфигурации в каталоге, который может быть прочитан анонимным веб-пользователем (но не написан).
Это трудно получить «правильно», потому что это зависит от конкретного варианта использования. Но вот что я сделал, когда у меня была очень похожая проблема.
Я установил общую библиотечную систему для небольшого количества веб-сайтов. Первоначально он предоставлял только обработчик базы данных, но был быстро добавлен уровень ORM. Большая часть роста после этого была дополнительным объектом, так как один из сайтов был переписан от прямого SQL к объектно-ориентированному доступу. Была также библиотека конфигурации, используемая для определения того, как объекты и другие элементы в общей библиотеке собирались вместе в «модули», а также настройки по умолчанию для таких вещей, как настройки базы данных. Он также поддерживал загрузку файла конфигурации за пределами дерева кодов, который использовался для настроек для каждого узла.
Поскольку объекты в слое ORM должны были настраиваться (это было статический вызов, чтобы сделать это, поскольку они были объявлены), было тривиально, чтобы он был расширен, чтобы запросить конкретную базу данных по имени. Затем нужно было убедиться, что все эти определения баз данных также были объявлены (и были преодолены благодаря универсальному механизму конфигурации).
(Это заняло некоторое время, но когда мы достигли точки разделения базы данных, было очень легко указать соответствующие объекты в другую базу данных, и все просто продолжало работать.)
Чтобы ответить на ваш вопрос, конфигурация была разделена. Имена и имена пользователей, имена пользователей и пароли были названы и определены в одном месте в области конфигурации кода. Но они могут быть переопределены на основе каждого узла. На объекты объекта были объявлены объекты. И это было также там, где конфигурации базы данных были указаны по имени.