Tạo một tệp cấu hình trong PHP

Tôi muốn tạo một tệp cấu hình cho dự án PHP của mình, nhưng tôi không chắc cách tốt nhất để thực hiện việc này là gì.

Tôi có 3 ý tưởng cho đến nay.

1-Sử dụng biến

$config['hostname'] = "localhost";
$config['dbuser'] = "dbuser";
$config['dbpassword'] = "dbpassword";
$config['dbname'] = "dbname";
$config['sitetitle'] = "sitetitle";

2-Sử dụng Const

define('DB_NAME', 'test');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');
define('TITLE', 'sitetitle');

Cơ sở dữ liệu 3-Sử dụng

Tôi sẽ sử dụng cấu hình trong các lớp vì vậy tôi không chắc cách nào sẽ là tốt nhất hoặc nếu có cách nào tốt hơn.

Một cách đơn giản nhưng thanh lịch là tạo một config.phptệp (hoặc bất cứ thứ gì bạn gọi) chỉ trả về một mảng:

<?php

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

Và sau đó:

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

Sử dụng tệp INI là một giải pháp linh hoạt và mạnh mẽ! PHP có một hàm riêng để xử lý nó đúng cách. Ví dụ: có thể tạo tệp INI như sau:

app.ini

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

[application]
app_email = mailer@myapp.com
app_url   = myapp.com

Vì vậy, điều duy nhất bạn cần làm là gọi:

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

Sau đó, bạn có thể truy cập các định nghĩa một cách dễ dàng bằng cách sử dụng $inimảng.

echo $ini['db_name'];     // mydatabase
echo $ini['db_user'];     // myuser
echo $ini['db_password']; // mypassword
echo $ini['app_email'];   // mailer@myapp.com

QUAN TRỌNG: Vì lý do bảo mật, tệp INI phải nằm trong thư mục không công khai

Tôi sử dụng một sự cải tiến nhỏ của giải pháp của @hugo_leonardo :

<?php

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

?>

Điều này cho phép bạn sử dụng cú pháp đối tượng khi bạn bao gồm php: $configs->hostthay vì $configs['host'].

Ngoài ra, nếu ứng dụng của bạn có các cấu hình bạn cần ở phía máy khách (như đối với ứng dụng Angular), bạn có thể có config.phptệp này chứa tất cả các cấu hình của mình (tập trung trong một tệp thay vì một tệp cho JavaScript và một tệp cho PHP). Sau đó, mẹo sẽ là có một tệp PHP khác echochỉ chứa thông tin phía máy khách (để tránh hiển thị thông tin bạn không muốn hiển thị như chuỗi kết nối cơ sở dữ liệu). Gọi nó nói get_app_info.php:

<?php

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

?>

Ở trên giả sử của bạn config.phpchứa một app_infotham số:

<?php

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

?>

Vì vậy, thông tin cơ sở dữ liệu của bạn vẫn ở phía máy chủ, nhưng thông tin ứng dụng của bạn có thể truy cập được từ JavaScript của bạn, ví dụ như một $http.get('get_app_info.php').then(...);loại lệnh gọi.

Các tùy chọn tôi thấy có điểm tương đối / điểm yếu là:

Cơ chế dựa trên tệp

Những điều này yêu cầu mã của bạn phải tìm ở các vị trí cụ thể để tìm tệp ini. Đây là một vấn đề khó giải quyết và luôn xuất hiện trong các ứng dụng PHP lớn. Tuy nhiên, bạn có thể sẽ cần giải quyết vấn đề để tìm mã PHP được kết hợp / sử dụng lại trong thời gian chạy.

Các cách tiếp cận phổ biến cho điều này là luôn sử dụng các thư mục tương đối hoặc tìm kiếm từ thư mục hiện tại trở lên để tìm một tệp có tên riêng trong thư mục cơ sở của ứng dụng.

Các định dạng tệp phổ biến được sử dụng cho tệp cấu hình là mã PHP, tệp được định dạng ini, JSON, XML, YAML và PHP được tuần tự hóa

Mã PHP

Điều này cung cấp một lượng lớn tính linh hoạt để biểu diễn các cấu trúc dữ liệu khác nhau và (giả sử nó được xử lý thông qua bao gồm hoặc yêu cầu) mã được phân tích cú pháp sẽ có sẵn từ bộ nhớ cache opcode - mang lại lợi ích về hiệu suất.

Đường bao gồm cung cấp một phương tiện để trừu tượng hóa các địa điểm tiềm năng của tập tin mà không dựa vào mã bổ sung.

Mặt khác, một trong những lý do chính để tách cấu hình khỏi mã là phân tách trách nhiệm. Nó cung cấp một lộ trình để đưa mã bổ sung vào thời gian chạy.

Nếu cấu hình được tạo từ một công cụ, có thể xác thực dữ liệu trong công cụ, nhưng không có chức năng chuẩn nào để thoát dữ liệu để nhúng vào mã PHP như tồn tại đối với HTML, URL, câu lệnh MySQL, lệnh shell ... .

Dữ liệu được tuần tự hóa Điều này tương đối hiệu quả đối với lượng cấu hình nhỏ (lên đến khoảng 200 mục) và cho phép sử dụng bất kỳ cấu trúc dữ liệu PHP nào. Nó yêu cầu rất ít mã để tạo / phân tích cú pháp tệp dữ liệu (vì vậy, thay vào đó bạn có thể dành nỗ lực của mình để đảm bảo rằng tệp chỉ được viết với sự ủy quyền thích hợp).

Việc thoát nội dung được ghi vào tệp được xử lý tự động.

Vì bạn có thể tuần tự hóa các đối tượng, nó tạo cơ hội cho việc gọi mã chỉ đơn giản bằng cách đọc tệp cấu hình (phương thức phép thuật __wakeup).

Tệp có cấu trúc

Lưu trữ nó dưới dạng tệp INI theo đề xuất của Marcel hoặc JSON hoặc XML cũng cung cấp một api đơn giản để ánh xạ tệp vào cấu trúc dữ liệu PHP (và ngoại trừ XML, để thoát dữ liệu và tạo tệp) trong khi loại bỏ lệnh gọi mã lỗ hổng bảo mật bằng cách sử dụng dữ liệu PHP được tuần tự hóa.

Nó sẽ có các đặc điểm hiệu suất tương tự như dữ liệu được tuần tự hóa.

Lưu trữ cơ sở dữ liệu

Điều này được coi là tốt nhất khi bạn có một lượng lớn cấu hình nhưng phải chọn lọc những gì cần thiết cho tác vụ hiện tại - Tôi đã rất ngạc nhiên khi thấy rằng với khoảng 150 mục dữ liệu, việc truy xuất dữ liệu từ phiên bản MySQL cục bộ nhanh hơn là hủy số liệu hóa một tệp dữ liệu.

OTOH không phải là nơi tốt để lưu trữ thông tin xác thực bạn sử dụng để kết nối với cơ sở dữ liệu của mình!

Môi trường thực thi

Bạn có thể đặt giá trị trong môi trường thực thi mà PHP đang chạy.

Điều này loại bỏ bất kỳ yêu cầu nào đối với mã PHP để tìm kiếm ở một vị trí cụ thể cho cấu hình. OTOH nó không mở rộng quy mô tốt với lượng lớn dữ liệu và rất khó thay đổi trên toàn cầu trong thời gian chạy.

Trên khách hàng

Một nơi mà tôi chưa đề cập để lưu trữ dữ liệu cấu hình là ở máy khách. Một lần nữa, chi phí mạng có nghĩa là điều này không mở rộng tốt với số lượng lớn cấu hình. Và vì người dùng cuối có quyền kiểm soát dữ liệu, dữ liệu đó phải được lưu trữ ở định dạng mà mọi hành vi giả mạo đều có thể phát hiện được (tức là với chữ ký mật mã) và không được chứa bất kỳ thông tin nào bị xâm phạm bởi việc tiết lộ (tức là được mã hóa có thể đảo ngược).

Ngược lại, điều này có rất nhiều lợi ích cho việc lưu trữ thông tin nhạy cảm thuộc sở hữu của người dùng cuối - nếu bạn không lưu trữ thông tin này trên máy chủ, nó không thể bị đánh cắp từ đó.

Thư mục mạng Một nơi thú vị khác để lưu trữ thông tin cấu hình là trong DNS / LDAP. Điều này sẽ hiệu quả đối với một số lượng nhỏ thông tin - nhưng bạn không cần phải tuân theo dạng thông thường đầu tiên - hãy xem xét, ví dụ như SPF .

Cơ sở hạ tầng hỗ trợ bộ nhớ đệm, sao chép và phân phối. Do đó, nó hoạt động tốt cho các cơ sở hạ tầng rất lớn.

Hệ thống kiểm soát phiên bản

Cấu hình, như mã nên được quản lý và kiểm soát phiên bản - do đó, lấy cấu hình trực tiếp từ hệ thống VC của bạn là một giải pháp khả thi. Nhưng thường thì điều này đi kèm với chi phí hiệu suất đáng kể, do đó, bộ nhớ đệm có thể được khuyến khích.

Chà - sẽ rất khó để lưu trữ dữ liệu cấu hình cơ sở dữ liệu của bạn trong một cơ sở dữ liệu - bạn có nghĩ vậy không?

Nhưng thực sự, đây là một câu hỏi khá nhiều ý kiến ​​bởi vì bất kỳ phong cách nào cũng hoạt động thực sự và tất cả đều là vấn đề sở thích. Cá nhân tôi thích biến cấu hình hơn là hằng số - nói chung là vì tôi không thích những thứ trong không gian chung trừ khi cần thiết. Không có chức năng nào trong codebase của tôi có thể dễ dàng truy cập mật khẩu cơ sở dữ liệu của tôi (ngoại trừ logic kết nối cơ sở dữ liệu của tôi) - vì vậy tôi sẽ sử dụng nó ở đó và sau đó có thể sẽ phá hủy nó.

Chỉnh sửa : để trả lời nhận xét của bạn - không có cơ chế phân tích cú pháp nào là nhanh nhất (ini, json, v.v.) - nhưng chúng cũng không phải là phần ứng dụng của bạn mà bạn thực sự cần tập trung vào việc tối ưu hóa vì sự khác biệt về tốc độ sẽ không đáng kể trên các tệp nhỏ như vậy.

Định nghĩa sẽ làm cho hằng số có sẵn ở mọi nơi trong lớp của bạn mà không cần sử dụng toàn cục, trong khi biến yêu cầu toàn cục trong lớp, tôi sẽ sử dụng DEFINE. nhưng một lần nữa, nếu các tham số db thay đổi trong quá trình thực thi chương trình, bạn có thể muốn gắn bó với biến.

Nếu bạn nghĩ rằng bạn sẽ sử dụng nhiều hơn 1 db vì bất kỳ lý do gì, hãy sử dụng biến vì bạn sẽ có thể thay đổi một tham số để chuyển sang một db hoàn toàn khác. Tức là để thử nghiệm, tự động sao lưu, v.v.

Bạn có thể tạo thuộc tính tĩnh phù thủy lớp cấu hình

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

thì bạn có thể đơn giản sử dụng nó:

Config::$dbHost  

Đôi khi trong các dự án của mình, tôi sử dụng mẫu thiết kế SINGLETON để truy cập dữ liệu cấu hình. Nó rất thoải mái khi sử dụng.

Tại sao?

Ví dụ, bạn có 2 nguồn dữ liệu trong dự án của mình. Và bạn có thể chọn phù thủy trong số họ được kích hoạt.

• mysql
• json

Ở đâu đó trong tệp cấu hình bạn chọn:

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

Khi bạn thay đổi nguồn toàn bộ ứng dụng, hãy chuyển sang nguồn dữ liệu mới, hoạt động tốt và không cần thay đổi mã.

Thí dụ:

Cấu hình:

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

Lớp 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;
    }
}

... và ở đâu đó trong mã của bạn (ví dụ: trong một số lớp dịch vụ):

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

Chúng ta có thể lấy một đối tượng AppConfig từ bất kỳ vị trí nào trong hệ thống và luôn nhận được cùng một bản sao (nhờ static). Phương thức init () của lớp được gọi là Trong phương thức khởi tạo, phương thức này chỉ đảm bảo một lần thực thi. Init () body kiểm tra giá trị của cấu hình $ dataSource và tạo đối tượng mới của lớp nguồn dữ liệu cụ thể. Bây giờ tập lệnh của chúng tôi có thể lấy đối tượng và hoạt động trên nó, thậm chí không biết triển khai cụ thể nào thực sự tồn tại.

Tôi thường kết thúc việc tạo một tệp conn.php duy nhất có các kết nối cơ sở dữ liệu của tôi. Sau đó, tôi đưa tệp đó vào tất cả các tệp yêu cầu truy vấn cơ sở dữ liệu.

Đây là cách của tôi.

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

?>

Mọi thắc mắc vui lòng comment