为什么要传递Config对象?设置不能是常量吗?


Why pass a Config object around? Can't the settings be constants?

在我的应用程序中,我有我的常量:

define('APP_PATH', WEB_ROOT . APP_DIR);
define('LIBS_PATH', APP_PATH . LIBS_DIR);
define('MODELS_PATH', APP_PATH . MODELS_DIR);
define('VIEWS_PATH', APP_PATH . VIEWS_DIR);
define('CONTROLLERS_PATH', APP_PATH . CONTROLLERS_DIR);
etc...

,因为一旦我的应用程序启动,它们将永远不会改变,并且它们很容易从任何类/方法中访问。

我也有一个配置文件与其他设置被导入到一个$config对象,我传递我的应用程序和检索它们,如:

$this->config->setting('some.setting');

我从来没有改变一个配置值在结束或在我的应用程序的中间,所以它不会更容易只是将它们定义为常量,这样我就可以访问他们在我的代码很容易?

我也不想静态地检索设置,也就是

Config::setting('some.setting');

我看一些PHP开发框架的代码,然后他们所有路径定义为常数,但在一些其他配置设置Config类尽管据我可以看到他们从未改变这些配置设置整个代码(他们可能尽管我没有成千上万的阅读每一行)和大量的这些框架似乎喜欢做静态调用各种方法从内部方法在不同的类和人说他们是好框架但是当涉及到类/方法中的静态调用时,我读到并经历了更多的坏而不是好的。

你认为最好如何处理配置设置?你是怎么做的?

在对象中包装常量使您的代码更易于移植。

这样你就可以在应用程序启动时从文件中加载常量,这样你就可以在任意数量的应用程序中重用你的代码,每个应用程序都有不同的配置文件。

从另一个角度来看,从类中加载内容就像一个转换:您可以将设置从文件移动到数据库,甚至硬编码它们,而整个应用程序都不会注意到。

当然,你可以在很小的项目中使用define

在配置对象中包装设置提供了封装,从而允许更好的共存。

例如,假设您有一个数据库访问框架。如果为此使用全局设置,则无法在单个程序中轻松访问多个数据库。将设置放入对象中允许您为相应的数据库使用特定的配置对象。