Is it right to set a config PHP class to keep project settings?

Question

I want to create a config.php file to keep the various configuration values that usually being changed from project to project, and I want to define a class to keep the config values in this file like the following:

class Config {
    const DB_SERVER    = 'localhost',
          DB_NAME      = 'abc',
          DB_USERNAME  = 'admin',
          DB_PASSWORD  = '12345',

          WEBSITE_NAME = 'My New Website',
          IMAGE_DIR    = 'img';
}

and so on, I want to define all values as constants inside the class, and I will call them like the following:

$connection = mysql_connect(Config::DB_SERVER, Config::DB_USERNAME, Config::DB_PASSWORD) or die("Database connection failed..");

I want to know: Is this way of setting the project configuration is right? Does this way have any cons? And if it was wrong, then what the best way to do this?

Solution 1

I've found these 2 articles that are talking about the same topic and I found that they are very useful so I wanted to share them here:

1- Using PHP classes to store configuration data
2- Using a PHP Class to Store Configuration

I hope they help as they did for me.

Solution 2

It's one way of doing it, yes. A not-too-bad way, IMO. Basically the class becomes a config file, just with PHP syntax.

There are a couple of drawbacks, though:

• You can't have const arrays or objects. (Course, you can't have global constant arrays/objects either, so...) (Since 5.6, you can have constant arrays. Still no const objects, though. I'm pretty sure you can't have const resources either, as that wouldn't make much sense.)

  You can work around this by implementing a static getter for objects (which of course is coded to always return the same object)...but i'd recommend against it in most cases. It is only a safe option if the objects in your config are immutable by design. (Objects that aren't designed for immutability are way too easy to change, even by accident.)

  (Aside from the mutability issue, it bugs me having actual running code in a config file...but that's mostly personal preference.)

• This class has a different purpose than the rest -- it's intended to change per project. You might consider keeping the Config class somewhere apart from the rest of the classes, like where you'd normally keep a config file.

• With a real config file, since you parse it at runtime, you could conceivably deal with a missing or invalid file (say, by running with default settings, using what parts are parsable, and/or showing a useful error message). But once your configuration is running as PHP code, any syntax errors -- or, if you haven't accounted for it, a missing Config class -- will stop the app dead in its tracks. And if you're running with display_errors off (recommended in production), the problem might be less than obvious.

Solution 3

I think, what you want is the static-keyword!

class Config {
    static $DB_SERVER    = 'localhost';
    static $DB_NAME      = 'abc';
    static $DB_USERNAME  = 'admin';
    static $DB_PASSWORD  = '12345';

    static $WEBSITE_NAME = 'My New Website';
    static $IMAGE_DIR    = 'img';
}

like that. You cann call them with ::, e.g. Config::$DB_SERVER.

Btw. normally you don't write them big like that if they are class variables. Big means globals, usually.

Comments

[Amr]

If I remove the word "const" and put "static" instead, they will no longer constants and will turn to be normal attributes, and in this case shouldn't I put the "$" in the front of each of them?

[erikbstack]

right, they need a $. I really thought you just confused both keywords. If you really just want constant behaviour it's normal in PHP to not put it in a class. If you want to call it without making an object of your Config class, then you will need the static, too, btw.

[BenMorel]

Note that since PHP 5.6, you can have arrays in constants!

[David]

Another drawback is testability. Any static part of the code is hard (or impossible) to mock properly during unit tests.

[cHao]

@David: Testability isn't really a drawback for config class constants vs other methods of configuration. Autoloading can make a custom config class easy...just load your replacement before anything needs it, and there ya go. The problem is that configuration itself complicates unit testing, as it inherently involves inter-unit relationships. Basically all configuration schemes have this same problem when misused. If testability is a goal, then your app's init code (and nothing else) should read config settings and parcel them out to everything else as constructor parameters etc.

[David]

If monkey patching is a feasible way, then yes, static dependencies are not a big deal. I prefer dynamic configuration objects that can be mocked without tinker around with the autoloader.

[kta]

You can use the final, rite?