Создание файла конфигурации в PHP

Одним простым, но элегантным способом является создание файла config.php (или того, что вы называете), который просто возвращает массив:

 <?php return array( 'host' => 'localhost', 'username' => 'root', ); ?> 

А потом:

 $configs = include('config.php'); 

Использование INI-файла – это гибкое и элегантное решение! PHP имеет встроенную функцию для правильной обработки. Например, можно создать INI-файл следующим образом:

 [database] db_name = mydatabase db_user = myuser db_password = mypassword [application] app_email = mailer@myapp.com app_url = myapp.com 

Поэтому вам нужно только позвонить:

 $ini = parse_ini_file('app.ini'); 

Затем вы можете легко получить доступ к определениям с помощью массива $ini .

 echo $ini['db_name']; // mydatabase echo $ini['db_user']; // myuser echo $ini['app_name']; // mypassword 

ВАЖНО: Из соображений безопасности файл INI должен находиться в не общедоступной папке

Я использую небольшую эволюцию решения @hugo_leonardo:

 <?php return (object) array( 'host' => 'localhost', 'username' => 'root', 'pass' => 'password', 'database' => 'db' ); ?> 

Это позволяет использовать синтаксис объекта, когда вы включаете php: $configs->host вместо $configs['host'] .

Кроме того, если у вашего приложения есть настройки, которые вам нужны на стороне клиента (например, для приложения с угловым), вы можете иметь этот файл config.php содержащий все ваши конфиги (централизованно в одном файле вместо одного для JavaScript и один для PHP). Тогда трюк должен был иметь еще один PHP-файл, который будет echo только информацию о стороне клиента (чтобы не показывать информацию, которую вы не хотите показывать, как строка подключения к базе данных). Назовите это: get_app_info.php :

 <?php $configs = include('config.php'); echo json_encode($configs->app_info); ?> 

Вышеприведенное предположение, что ваш config.php содержит параметр app_info :

 <?php return (object) array( 'host' => 'localhost', 'username' => 'root', 'pass' => 'password', 'database' => 'db', 'app_info' => array( 'appName'=>"App Name", 'appURL'=> "http://yourURL/#/" ) ); ?> 

Таким образом, информация вашей базы данных остается на стороне сервера, но ваша информация о приложении доступна из вашего JavaScript, например, с помощью $http.get('get_app_info.php').then(...); тип вызова.

Ну, было бы сложно хранить данные конфигурации базы данных в базе данных – не так ли?

Но на самом деле, это довольно упрямый вопрос, потому что любой стиль действительно работает, и все это зависит от предпочтений. Лично я бы выбрал переменную конфигурации, а не константы – вообще, потому что мне не нравятся вещи в глобальном пространстве, если это необходимо. Ни одна из функций моей кодовой базы не должна иметь возможности легко получить доступ к моему паролю базы данных (кроме моей логики подключения к базе данных), поэтому я бы использовал его там, а затем, вероятно, уничтожил его.

Изменить : чтобы ответить на ваш комментарий – ни один из механизмов синтаксического анализа не был бы самым быстрым (ini, json и т. Д.), Но они также не являются частями вашего приложения, которые вам действительно нужно сосредоточить на оптимизации, поскольку разница в скорости будет быть пренебрежимо малыми в таких маленьких файлах.

Я довольно удивлен принятым ответом здесь, и число его возвышений. За исключением ответа Марсио Маццукато, нет обсуждения относительных достоинств / слабых сторон любого из нескольких подходов.

Возможные варианты:

Файловые механизмы

Для этого требуется, чтобы ваш код выглядел в определенных местах, чтобы найти ini-файл. Это сложная проблема для решения, которая всегда возникает в больших PHP-приложениях. Однако вам, скорее всего, придется решить проблему, чтобы найти код PHP, который включается / повторно используется во время выполнения.

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

Обычные форматы файлов, используемые для файлов конфигурации, – это PHP-код, ini-форматированные файлы, JSON, XML, YAML и сериализованный PHP

PHP-код

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

Include_path предоставляет средство для абстрагирования потенциальных мест размещения файла, не полагаясь на дополнительный код.

С другой стороны, одной из основных причин разделения конфигурации кода является разделение обязанностей. Он обеспечивает маршрут для ввода дополнительного кода во время выполнения.

Если конфигурация создается из инструмента, может быть возможно проверить данные в инструменте, но нет стандартной функции для удаления данных для встраивания в PHP-код, как это существует для HTML, URL-адресов, операторов MySQL, команд оболочки … ,

Сериализованные данные Это относительно эффективно для небольших объемов конфигурации (до 200 единиц) и позволяет использовать любую структуру данных PHP. Для создания / анализа файла данных требуется очень мало кода (так что вы можете вместо этого потратить свои усилия на то, чтобы файл был написан только с соответствующей авторизацией).

Экранирование содержимого, записанного в файл, обрабатывается автоматически.

Поскольку вы можете сериализовать объекты, это создает возможность для вызова кода, просто прочитав файл конфигурации (метод магии __wakeup).

Структурированный файл

Хранение его как файла INI, предложенного Marcel или JSON или XML, также предоставляет простой api для сопоставления файла в структуру данных PHP (и за исключением XML, чтобы избежать данных и создания файла), в то же время устраняя вызов кода с использованием сериализованных данных PHP.

Он будет иметь схожие характеристики производительности с сериализованными данными.

Базы данных

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

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

Условия выполнения

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

Это устраняет любые требования к тому, чтобы PHP-код выглядел в определенном месте для конфигурации. OTOH не очень хорошо масштабируется для больших объемов данных и его трудно изменить повсеместно во время выполнения.

На клиенте

Одно место, которое я не упоминал для хранения данных конфигурации, – у клиента. Опять же, сетевые накладные расходы означают, что это не очень хорошо масштабируется для больших объемов конфигурации. И поскольку конечный пользователь имеет контроль над данными, он должен храниться в формате, в котором может быть обнаружено какое-либо искажение (т. Е. С криптографической подписью), и не должно содержать никакой информации, которая скомпрометирована ее раскрытием (т.е. обратимо зашифрованной).

И наоборот, у этого есть много преимуществ для хранения конфиденциальной информации, которая принадлежит конечному пользователю – если вы не храните это на сервере, ее нельзя украсть.

Сетевые каталоги Еще одно интересное место для хранения информации о конфигурации содержится в DNS / LDAP. Это будет работать для небольшого количества небольших фрагментов информации, но вам не нужно придерживаться 1-й нормальной формы – считайте, например, SPF .

Инфраструктура поддерживает кеширование, репликацию и распространение. Следовательно, он хорошо работает для очень больших инфраструктур.

Системы контроля версий

Конфигурация, как и код, должна управляться и контролироваться версией – поэтому получение конфигурации непосредственно из вашей системы VC является жизнеспособным решением. Но часто это приводит к значительным накладным расходам, поэтому кэширование может быть целесообразным.

Обычно я создаю единственный файл conn.php с моими подключениями к базе данных. Затем я включаю этот файл во все файлы, требующие запросов к базе данных.

Define сделает константу доступной повсюду в вашем классе, не используя глобальную, в то время как переменная требует глобального класса, я бы использовал DEFINE. но опять же, если параметры db должны меняться во время выполнения программы, вы можете захотеть придерживаться переменной.

Если вы думаете, что по какой-то причине вы будете использовать более 1 дБ, перейдите к переменной, потому что вы сможете изменить один параметр, чтобы переключиться на совершенно другой бит. Т.е. для тестирования, autobackup и т. Д.

Вот мой путь.

 <?php define('DEBUG',0); define('PRODUCTION',1); #development_mode : DEBUG / PRODUCTION $development_mode = PRODUCTION; #Website root path for links $app_path = 'http://192.168.0.234/dealer/'; #User interface files path $ui_path = 'ui/'; #Image gallery path $gallery_path = 'ui/gallery/'; $mysqlserver = "localhost"; $mysqluser = "root"; $mysqlpass = ""; $mysqldb = "dealer_plus"; 

?>

Любые сомнения, пожалуйста, прокомментируйте

Вы можете создавать статические свойства класса класса конфигурации

 class Config { static $dbHost = 'localhost'; static $dbUsername = 'user'; static $dbPassword = 'pass'; } 

то вы можете просто использовать его:

 Config::$dbHost 

Иногда в моих проектах я использую шаблон проектирования SINGLETON для доступа к данным конфигурации. Это очень удобно в использовании.

Зачем?

Например, у вас есть 2 источника данных в вашем проекте. И вы можете выбрать, что ведьма из них включена.

• MySQL
• JSON

Где-то в файле конфигурации вы выбираете:

 $dataSource = 'mysql' // or 'json' 

Когда вы меняете исходное целое приложение shoud на новый источник данных, работайте нормально и не нуждаетесь в изменении кода.

Пример:

Config:

 class Config { // .... static $dataSource = 'mysql'; / ..... } 

Singleton класс:

 class AppConfig { private static $instance; private $dataSource; private function __construct() { $this->init(); } private function init() { switch (Config::$dataSource) { case 'mysql': $this->dataSource = new StorageMysql(); break; case 'json': $this->dataSource = new StorageJson(); break; default: $this->dataSource = new StorageMysql(); } } public static function getInstance() { if (empty(self::$instance)) { self::$instance = new self(); } return self::$instance; } public function getDataSource() { return $this->dataSource; } } 

… и где-то в вашем коде (например, в каком-либо классе обслуживания):

 $container->getItemsLoader(AppConfig::getInstance()->getDataSource()) // getItemsLoader need Object of specific data source class by dependency injection 

Мы можем получить объект AppConfig из любого места в системе и всегда получать одну и ту же копию (благодаря статическому). Метод init () класса вызывается в конструкторе, который гарантирует только одно выполнение. Init () проверяет тело значение config $ dataSource и создает новый объект определенного класса источника данных. Теперь наш скрипт может получить объект и работать с ним, не зная даже, какая конкретная реализация действительно существует.