What is the best way to represent configuration options internally?

Question

So, I am looking at a number of ways to store my configuration data. I believe I've narrowed it down to 3 ways:

Just a simple variable

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

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

I think that this is just too mutable, where as the configuration options shouldn't be able to be changed.

A Modified Standard Class

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'];

Basically, all it does is encapsulates the above array into an object, and makes sure that the object can not be changed.

Or a Static Class

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

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

This provides the ultimate immutability, but it also means that I would have to go in and manually edit the class whenever I wanted to change the data.

Which of the above do you think would be best to store configuration options in? Or is there a better way?

Answer 1

I'd go with whats behind door #3.

It looks easier to read and understand than #2, and seems to meet your needs better than #1.

Answer 2

Take a look at this question for ideas on storing the config data in a separate file:

http://stackoverflow.com/questions/2015715/fastest-way-to-store-easily-editable-config-data-in-php

I'd use method #2 pulling the config data as an array from an external file.

Answer 3

Of those 3 options, a static method is probably the best.

Really, though, "the best" is ultimately about what's easiest and most consistent for you to use. If the rest of your app isn't using any OO code then you might as well go with option #1. If you are ultimately wanting to write a whole db abstraction layer, option #2.

Without knowing something more about what your goals are and what the rest of your app looks like, it's kind of like asking someone what the best motor vehicle is -- it's a different answer depending on whether you're looking for a sports car, a cargo truck, or a motorcycle.

Answer 4

The best way is that which fits your application best.

For a small app, it might be totally sufficient to use an array, even it is mutable. If no one is there to modify it except you, it doesn't have to be immutable.

The second approach is very flexible. It encapsulates data, but does not know anything about it. You can pass it around freely and consuming classes can take from it what they need. It is generic enough to be reused and it does not couple the config class to the concrete application. You could also use an interface with this or similar classes to allow for type hints in your method signatures to indicate a Config is required. Just don't name it stdDataClass, but name it by it's role: Config.

Your third solution is very concrete. It hardcodes a lot of assumptions about what your application requires into the class and it also makes it the responsibility of the class to know and provide this data through getters and setters. Depending on the amount of components requiring configuration, you might end up with a lot of specific getters. Chances are pretty good you will have to rewrite the entire thing for your next app, just because your next app has different components.

I'd go with the second approach. Also, have a look at Zend_Config, as it meets all your requirements already and let's you init the Config object from XML, Ini and plain arrays.