Каков наилучший способ представления параметров конфигурации внутри? - PullRequest
4 голосов
/ 10 января 2010

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

Просто простая переменная

$config = array(
    "database" => array(
        "host" => "localhost",
        "user" => "root",
        "pass" => "",
        "database" => "test"
    )
);

echo $config['database']['host'];

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

Модифицированный стандартный класс

class stdDataClass {

    // Holds the Data in a Private Array, so it cannot be changed afterwards.
    private $data = array();

    public function __construct($data)
    {
        // ......
       $this->data = $data;
        // .....
    }

   // Returns the Requested Key
   public function __get($key)
   {
        return $this->data[$key];
   }

   // Throws an Error as you cannot change the data.
   public function __set($key, $value)
   {
         throw new Exception("Tried to Set Static Variable");
    }
}

$config = new stdStaticClass($config_options);
echo $config->database['host'];

По сути, все, что он делает - это инкапсулирует вышеуказанный массив в объект и гарантирует, что объект не может быть изменен.

Или статический класс

 class AppConfig{
    public static function getDatabaseInfo()
    {
          return array(
            "host" => "localhost",
            "user" => "root",
            "pass" => "",
            "database" => "test"
        );   
    }
    // .. etc ...
}

$config = AppConfig::getDatabaseInfo();
echo $config['host'];

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

Как вы думаете, в каком из вышеперечисленных вариантов лучше всего хранить параметры конфигурации? Или есть лучший способ?

Ответы [ 4 ]

3 голосов
/ 10 января 2010

Из этих трех вариантов статический метод, вероятно, является лучшим.

Действительно, «лучшее» в конечном счете - это то, что вам проще всего и проще всего использовать. Если в остальной части вашего приложения не используется какой-либо OO-код, вы можете использовать вариант № 1. Если вы в конечном итоге хотите написать целый слой абстракции БД, выберите вариант 2.

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

1 голос
/ 10 января 2010

Способ best - это то, что лучше всего подходит для вашего приложения.

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

Второй подход очень гибкий. Он инкапсулирует данные, но ничего о них не знает. Вы можете свободно распространять его, а классы-потребители могут извлекать из него все, что им нужно. Он достаточно универсален для повторного использования и не связывает класс конфигурации с конкретным приложением. Вы также можете использовать интерфейс с этим или подобными классами, чтобы разрешить подсказки типов в сигнатурах вашего метода, чтобы указать, что требуется Config. Только не называйте это stdDataClass, а назовите его по роли: Config.

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

Я бы пошел со вторым подходом. Также обратите внимание на Zend_Config , так как он уже отвечает всем вашим требованиям и позволяет вам инициализировать объект Config из XML, Ini и простых массивов.

1 голос
/ 10 января 2010

Посмотрите на этот вопрос, чтобы узнать, как сохранить данные конфигурации в отдельном файле:

Самый быстрый способ хранить легко редактируемые данные конфигурации в PHP?

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

1 голос
/ 10 января 2010

Я бы пошел с тем, что за дверью № 3.

Это выглядит легче для чтения и понимания, чем # 2, и, кажется, отвечает вашим потребностям лучше, чем # 1.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...