Criar um ficheiro de configuração no PHP
quero criar um ficheiro de configuração para o meu projecto PHP, mas não tenho a certeza qual é a melhor maneira de fazer isto.
Tenho duas ideias até agora.1-Usar A Variável
$config['hostname'] = "localhost";
$config['dbuser'] = "dbuser";
$config['dbpassword'] = "dbpassword";
$config['dbname'] = "dbname";
$config['sitetitle'] = "sitetitle";
2-Utilizar Const
define('DB_NAME', 'test');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');
define('TITLE', 'sitetitle');
3-Usar A Base De Dados
Vou usar a configuração nas aulas, por isso não sei qual seria o melhor ou se há uma maneira melhor.10 answers
Uma forma simples, mas elegante, é criar um ficheiro config.php
(ou seja lá como lhe chamas) que apenas devolve uma matriz:
<?php
return array(
'host' => 'localhost',
'username' => 'root',
);
E depois:
$configs = include('config.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(...);
.
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
serializadoPHP 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.
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.
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.
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.
<?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