Yii2：配置参数与 const/define答案

【问题标题】：Yii2: Config params vs. const/defineYii2：配置参数与 const/define
【发布时间】：2015-04-03 17:29:29
【问题描述】：

我应该什么时候使用？

我可以选择在 index.php 入口脚本文件中定义常量，就像Yii2 guide: constants 中推荐的那样。或者我可以使用配置中的参数 - 在YII2 guide: params 中解释。两者都是每个应用程序，而不是真正的全球性。

目前，在我看来，如果我想组合这样的值，params 会不太舒服：

define('SOME_URL',            'http://some.url');
define('SOME_SPECIALIZED_URL', SOME_URL . '/specialized');

此外，与常量相比，访问代码（Yii::$app->params['something']）更多。

那么我什么时候应该或可以使用什么？

小更新：在 PHP 7 中 define() 也支持数组，因此整个 params 结构可以配置为常量。 IDE 可能更好地支持。

【问题讨论】：

我不记得任何关于它的具体建议。我个人更喜欢参数。常量的优点：编写的代码更少，IDE 自动完成支持。
您可以使用常量仅存储原始值 - 数字、字符串、布尔值等。对于复杂数据，您必须选择参数（因为您无法将数组和对象存储在常量中），并且通常需要将数据组织在逻辑组中。
另外，当您使用一些部署工具时，您可以为不同的部署环境设置不同的值。当您只有在每个环境中都相同的值时，应该使用常量
如果你需要在任何地方使用值，请使用 Yii::$app->params。但是，如果您将使用一次 value，那么我建议您只使用常量。但请记住，在 Yii::$app->params 中，您可以使用环境变量，例如 getenv('any_key');

标签： php configuration config yii2

【解决方案1】：

常量的主要缺点（同时也是优点）是它们是……常量。一旦设置，就无法更改。这是这里唯一重要的事情。您应该将常量用于在执行期间永远不会更改的值，并将参数用于其他所有内容。

当您开始为您的应用编写测试时，常量可能是一个真正的 PITA。它会告诉你，许多你认为恒定的事情并不是真正恒定的。此时参数更加灵活 - 您可以使用配置数组的合并轻松更改它们或在配置级别进行调整。使用常量可能会使您陷入不可配置应用程序的陷阱，如果不修改硬编码常量，就无法将其安装在不同的环境中。

此外，与常量相比，访问代码（Yii::$app->params['something']）更多。

这完全无关紧要。作为一名程序员，你花在实际编写代码上的时间不到 5%。额外的 10 次击键不会产生任何影响。您应该始终从可读性的角度考虑它。您编写代码一次并阅读数百次，因此阅读和理解代码所需的时间比编写代码所花费的时间重要得多。并且使用已知的约定（Yii::$app->params 就是其中之一）使您的代码更易于理解，尤其是对于其他程序员而言。

但如果你真的想写更少的代码，你总是可以创建一个包装函数来短时间访问参数。

function p($name) {
    return Yii::$app->params[$name];
}

echo p('my-param');

【讨论】：

“常量的主要缺点（同时也是优点）是它们是……常量”，这就是它被称为 CONFIG 的原因。哪个必须是恒定的......不像设置
什么叫“配置”和设置有什么区别？你在这里使用了一些自制的术语，不要指望人们会理解你在说什么。另请注意，在极少数情况下，某些设置需要保持不变，而无法在同一请求中更改它可能会在测试期间出现问题。
欢迎来到 IT 世界！ wikidiff.com/configuration/setting
你读过这个定义吗？它看起来不像 IT 相关的。但是，即使您不能将应用配置视为恒定不变，硬编码诸如 URL 之类的东西也只是在自找麻烦，并且在某种程度上证明了您没有进行适当的测试。
配置 [通常] 仅在应用程序安装、需要初始化或设置一些基本要求时写入/存储一次（如数据库内容、应用程序路径、错误处理内容...） .它也很少改变。这就是它存储在平面文件中的原因。与不存储与基础设施相关的东西并且每天都在变化的设置/首选项不同（如字体大小、颜色等）。这就是为什么它们存储在数据库中（通常）。您不必将它们混合在一个术语中，只是因为您不喜欢它或无法理解它们的差异！

【解决方案2】：

我倾向于使用 Yii 应用程序参数。主要原因是这些参数中保存的值往往会根据代码运行的环境而变化。所以我将有一个运行的构建系统（我使用Phing）并从非版本控制文件，例如 build.properties。

因此，任何开发数据库设置、开发域设置、api 沙箱地址等都将加载到我的开发环境中，并且在实时服务器上运行构建时将使用正确的生产值。

如果您在某种 php 文件中设置这些值，那么使用版本控制进行跟踪就会出现问题，因为每次您在开发环境中构建时都会对 index.php 文件进行更改。有人甚至可能最终错误地提交了这些更改。

总而言之，我会说如果它们是真正的常量——在代码运行的任何环境中都是一样的——它们可能是一个常量。如果这些值可能会发生变化，具体取决于代码运行的位置，那么我的偏好是将它们放在参数中，并让您的构建系统从非版本控制文件中加载它们。

【讨论】：