为什么要传递一个 Config 对象？设置不能是常数吗？答案

【问题标题】：Why pass a Config object around? Can't the settings be constants?为什么要传递一个 Config 对象？设置不能是常数吗？
【发布时间】：2013-01-01 13:35:31
【问题描述】：

在我的应用程序中，我有我的常量：

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 类中还有其他配置设置，尽管据我所知，它们从不更改这些配置设置代码（它们可能因为我没有通读成千上万行中的每一行），而且许多框架似乎喜欢从不同类的方法中对各种方法进行静态调用，人们说它们是很好的框架，但是当涉及到类/方法中的静态调用时，我已经阅读并经历了更多的坏事。

您认为如何最好地处理配置设置？你做什么工作？

【问题讨论】：

这些框架的其他特性之一是能够为不同的环境提供不同的配置，具有继承性，因此（例如）您的配置文件可以定义测试环境从开发环境继承设置，除非定义了具体的测试设置
有道理，但是要访问配置设置，您是否不必将$config 对象的实例注入所有需要设置的对象中？或者做一个像Config::setting('some.setting');这样的静态调用来获取你的设置还是有其他方法？
确实需要静态注入或访问；这正是大多数框架访问配置的方式。使用依赖注入容器 (DIC) 可以简化您向每个类中注入的内容
只将所需的值注入到对象中，而不是传递配置，这样更简洁。仅在初始化期间需要配置。

标签： php instantiation

【解决方案1】：

将常量包装在对象中使您的代码更具可移植性。

这样，您可以在应用程序引导时从文件加载常量，这样您就可以在任意数量的应用程序中重复使用您的代码，每个应用程序都有不同的配置文件。

在另一个程度上，从类中加载内容就像一种外观：您可以将设置从文件移动到数据库，甚至对它们进行硬编码，而整个应用程序都不会注意到。

当然，对于非常小的项目，您可以使用 define。

【讨论】：

我想我会继续保留我的 Config 类，以便将来可扩展。我有一个依赖注入容器，它自动检索$config 对象的实例并通过我的对象的构造函数注入它，以便他们可以使用它。这不是很麻烦，但有更好的方法吗？还是那是最好的方法？谢谢。

【解决方案2】：

在配置对象中包装设置提供了封装，从而实现了更好的共存。

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

【讨论】：