Criar um ficheiro de configuração no PHP

Usar um ficheiro INI é uma solução flexível e poderosa! PHP tem uma função nativa para lidar com isso corretamente. Por exemplo, é possível criar um arquivo INI como este:

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

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

Então a única coisa que precisas de fazer é ligar-me.

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

Então você pode acessar as definições facilmente usando a matriz $ini.

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

Importante: por razões de segurança, o ficheiro INI deve estar numa pasta não pública

USO UMA ligeira evolução da solução de @hugo_leonardo :

<?php

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

?>

Isto permite-lhe usar a sintaxe do objecto quando incluir o php : $configs->host em vez de $configs['host'].

Também, se a sua aplicação tiver configurações que necessita do lado do cliente (como para uma aplicação Angular), poderá ter este ficheiro config.php que contém todas as suas configurações (centralizado num ficheiro em vez de um para o JavaScript e outro para o PHP). O truque seria então ter outro arquivo PHP que iria echo apenas o informação do lado do cliente (para evitar mostrar informação que não deseja mostrar como o texto da ligação à base de dados). Chama-lhe "diz".get_app_info.php :

<?php

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

?>

O acima, assumindo que o seu config.php contém um parâmetro app_info:

<?php

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

?>

A informação da sua base de dados permanece do lado do servidor, mas a informação da sua aplicação está acessível a partir do seu JavaScript, com, por exemplo, um tipo de chamada $http.get('get_app_info.php').then(...);.

Estou bastante surpreendido com a resposta aceite e com o número de votos positivos que obteve. Com exceção da resposta de Marcio Mazzucato, não há discussão sobre os méritos / fraquezas relativos de qualquer uma das várias abordagens.

As opções que vejo são:

Mecanismos baseados em ficheiros

Estes requerem que o seu código procure em locais específicos para encontrar o ficheiro ini. Este é um problema difícil de resolver e que sempre aparece em grande PHP aplicacao. No entanto, você provavelmente terá que resolver o problema, a fim de encontrar o código PHP que é incorporado / reutilizado no tempo de execução.

As abordagens comuns a isto São usar sempre pastas relativas, ou procurar a partir do directório actual para cima para encontrar um ficheiro com nome exclusivo na pasta de base da aplicação.

Os formatos de ficheiros comuns utilizados para os ficheiros de configuração são o código PHP, ficheiros formatados ini, JSON, XML, YAML e PHP

serializado

PHP código

Isto proporciona uma enorme flexibilidade para representar diferentes estruturas de dados ,e (assumindo que é processado através de include ou require) o código processado estará disponível a partir da cache do opcode - dando um benefício de desempenho.

O include_ Path fornece um meio para abstrair as localizações potenciais do ficheiro sem depender de um código adicional.

Por outro lado, uma das principais razões para separar a configuração do código é a responsabilidades separadas. Ele fornece uma rota para injetar código adicional no tempo de execução.

Se a configuração é criada a partir de uma ferramenta, pode ser possível validar os dados na ferramenta, mas não existe uma função padrão para escapar de dados para incorporar no código PHP como existe para HTML, URLs, instruções MySQL, comandos shell....

Dados serializados Isto é relativamente eficiente para pequenas quantidades de configuração (até cerca de 200 itens) e permite o uso de qualquer Estrutura de dados PHP. Ele requer muito pouco código para criar/processar o arquivo de dados (então você pode, em vez disso, gastar seus esforços para garantir que o arquivo é escrito apenas com a autorização apropriada).

A Fuga do conteúdo gravado no ficheiro é tratada automaticamente.

Uma vez que você pode serializar objetos, ele cria uma oportunidade para invocar o código simplesmente lendo o arquivo de configuração (o método __wakeup magic).

Ficheiro estruturado

Conservação O arquivo INI, como sugerido por Marcel ou JSON ou XML, também fornece uma api simples para mapear o arquivo em uma estrutura de dados PHP (e com exceção de XML, para escapar dos dados e criar o arquivo), eliminando a vulnerabilidade de Invocação de código usando dados PHP serializados.

Terá características de desempenho semelhantes aos dados serializados.

Armazenamento de bases de Dados

Isto é melhor considerado quando você tem uma grande quantidade de configuração, mas são seletivos no que é necessário para a tarefa atual - fiquei surpreso ao descobrir que em cerca de 150 itens de dados, foi mais rápido para recuperar os dados de uma instância local MySQL do que para deserializar um datafile.

OTOH não é um bom lugar para armazenar as credenciais que você usa para se conectar à sua base de dados!

O ambiente de execução

Você pode definir os valores no ambiente de execução em que o PHP está a correr.

Isto remove qualquer requisito para o código PHP procurar num lugar para a config. OTOH ele não escala bem para grandes quantidades de dados e é difícil de mudar universalmente em tempo de execução.

No cliente

Um lugar que não mencionei para armazenar dados de configuração é no cliente. Mais uma vez, o overhead da rede significa que isso não escala bem para grandes quantidades de configuração. E uma vez que o utilizador final tem controlo sobre os dados, estes devem ser armazenados num formato em que seja detectável qualquer manipulação abusiva (isto é, com uma assinatura criptográfica). e não deve conter qualquer informação que seja comprometida pela sua divulgação (isto é, reversivelmente criptografada). Por outro lado, isto tem um monte de benefícios para armazenar informações sensíveis que é propriedade do usuário final - se você não está armazenando isso no servidor, ele não pode ser roubado de lá.

Directórios De Rede Outro lugar interessante para armazenar informações de configuração é em DNS / LDAP. Isto irá funcionar para um pequeno número de pequenas informações-mas você não é necessário manter a primeira forma normal-Considere, por exemplo SPF.

A infra-estrutura suporta Cache, replicação e distribuição. Por isso, funciona bem para infra-estruturas muito grandes.

Sistemas de controlo de versões

Configuração, como o código deve ser gerenciado e Versão Controlada - portanto, obter a configuração diretamente do seu sistema VC é uma solução viável. Mas muitas vezes isso vem com um desempenho significativo overhead, daí caching pode ser aconselhavel.

Seria difícil armazenar os dados de configuração da sua base de dados numa base de dados, não acha? Mas, na verdade, esta é uma questão bastante opinativa porque qualquer estilo Funciona realmente e é tudo uma questão de preferência. Pessoalmente, eu optaria por uma variável de configuração ao invés de constantes - geralmente porque eu não gosto de coisas no espaço global a menos que necessário. Nenhuma das funções na minha base de dados deve ser capaz de aceder facilmente à minha senha de base de dados então, eu usava-o lá e, provavelmente, destruía-o.

Edit: para responder seu comentário - nenhum dos mecanismos de análise seria mais rápido (ini, json, etc) - mas eles também não são partes do aplicativo que você realmente precisa para se concentrar em otimização, pois a diferença de velocidade seria insignificante em tais arquivos pequenos.

Normalmente acabo por criar um único comando.ficheiro php que tem as minhas ligações à base de dados. Então eu incluo esse arquivo em todos os arquivos que requerem consultas de banco de dados.

Definir tornará a constante disponível em todos os lugares da sua classe sem necessidade de usar global, enquanto a variável requer global na classe, eu usaria definir. mas novamente, se o db params deve mudar durante a execução do programa você pode querer ficar com variável.

Se você acha que vai estar usando mais de 1 db por qualquer razão, vá com a variável porque você será capaz de mudar um parâmetro para mudar para um db completamente diferente. Ou seja , para ensaios, autobackup, etc.

Podes criar uma classe de config, propriedades estáticas de bruxas.

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

Então você pode simplesmente usá-lo:

Config::$dbHost  

---

Às vezes, nos meus projectos, uso um padrão de design SINGLETON para aceder aos dados de configuração. É muito confortável em uso. Porquê?

Por exemplo, tem 2 Fontes de dados no seu projecto. E você pode escolher a bruxa deles é habilitado.

• mysql
• json

Algures no ficheiro de configuração, você escolhe:

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

Quando você muda o aplicativo de código completo shoud mudar para nova fonte de dados, trabalhar bem e não precisa de mudança de código.

Exemplo:

Configuração:

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

Classe 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;
    }
}

... e em algum lugar em seu código (eg. em alguma classe de Serviço):

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

Podemos obter um objecto AppConfig de qualquer lugar do sistema e obter sempre a mesma cópia (graças à estática). O método init () da classe é chamado No construtor, que garante apenas uma execução. Init () body controlo O valor da config $dataSource, e criar um novo objeto de classe de fonte de dados específica. Agora nosso script pode obter objeto e operá-lo, sem saber mesmo que exista uma implementação específica.

Este é o meu caminho.

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

?>

Por favor, comente