PHP Zend Framework - Zend_Config and global state

Question

I'm in the process of evaluating the benefits of Zend_Config_Ini versus using a simple constant file.

e.g. -

define('DB_HOST',localhost);

//versus

$config = new Zend_Config_Ini('/path/to/config.ini', 'staging');
echo $config->database->params->host;   // prints "dev.example.com"

The only thing is that the $config is not globally accessible. So then you need to use Zend_Registry to store for application usage, without having to initiate each time.

This seems to add more complexity than needed.... am I missing something or is Zend_Config + Zend_Registry a technique that is better in the long run as an app grows?

Answer 1

A nice advantage of Zend_Config is that you don't depend on a "PHP source code file" ; just a .ini file will do -- and some prefer modifying an .ini file instead of a PHP one.

And it's easier to modify an .ini / XML file programatically - there are classes / functions to do that !

With .ini files and Zend_Config, you also have nice functionnalities already provided ; for instance, inheritance between sections (ie, you can have a "generic" section, and "staging" and "production" that overwrite some values)

A thing that can be insteresting about Zend_Config, too, is consitency : Zend Framework, with Zend_Application, already supposes you'll have one configuration file ; so, why not a second one ? Or even re-use the first one ?

And it's the same with several classes of the Framework, which can work or be configured with an instance of Zend_Config ; if you already have that one, it suddenly becomes easier ;-)

If I had to choose between a PHP file with defines and a .ini file, for things that are configurable, I would probably go with the .ini file (And Zend_Config + Zend_Registry when needed).

Answer 2

The main advantage of using the Registry with a config is to avoid polluting the global namespace. Say, you want to include a third party lib and your app and the lib both define a constant DB_HOST. No good.

In addition, many of the factories in Zend Framework utilize the config object to create instances. Zend_Db is a good example of this. You just pass it $this->database and it will take what it needs to instantiate your adapter.

You can also extend the registry with custom functionality, e.g. finder methods or stuff like that. Check the pattern description by Fowler.

Answer 3

Yes, you're correct, using the Zend sanctioned method for configuration is more complex than defining a series of global constants. The advantages you get are

No Global Namespace Collisions

If you ever need to integrate your application with another project, having global constants represent your application config may cause problems. What are the chances another project has a constant named DB_HOST? How can a developer who's using your hybrid system tell which constants are the config for your application vs. the integrated application?

Building on the Work of Others

So, you have a single file with all your config values. How are you going to deploy that into different environments? (production, staging, etc.) Chances are you're a smart person who could come up with a solution, but how is another developer coming into your project going to know how that solution works? How are other modules in your application going to know how to read your global config?

Zend_Config has already "solved" many of the problems. By taking on a bit more complexity and abstraction up-front you get a known path forward, and can spend more time on solving the problems of your application instead of inventing and supporting Yet Another Configuration System.