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

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

[database]
db_name     = mydatabase
db_user     = myuser
db_password = mypassword

[application]
app_email = [email protected]
app_url   = myapp.com

так что единственное, что вам нужно сделать, это позвонить:

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

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

echo $ini['db_name'];     // mydatabase
echo $ini['db_user'];     // myuser
echo $ini['db_password']; // mypassword
echo $ini['app_email'];   // [email protected]

важно: по соображениям безопасности INI-файл должен находиться в непубличной папке

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

<?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 содержит элемент :

<?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. Это трудная проблема для решения и тот, который всегда появляется в больших PHP-приложениях. Однако вам, вероятно, придется решить эту проблему, чтобы найти PHP-код, который будет включен / повторно использован во время выполнения.

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

общие форматы файлов, используемые для конфигурационных файлов являются PHP код, ini форматированные файлы, JSON, XML, YAML и сериализованные PHP

PHP-кода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Config::$dbHost  

---

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

почему?

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

• mysql
• json

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

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

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

пример:

Config:

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

Синглтон-класс:

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, и создать новый объект определенного класса источника данных. Теперь наш скрипт может достать объект и оперировать на нем, не зная даже какая конкретная реализация на самом деле существует.

вот мой путь.

<?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";

?>

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