4

PSR-1包括建议2.3。副作用：

文件应该声明新符号（类、函数、常量等）并且不会引起其他副作用，或者它应该执行具有副作用的逻辑，但不应该两者都做。

考虑 config.php 文件中的这个例子（我自己的）：

/**
 * Parsing the database URL.
 * DATABASE_URL is in the form:
 *  postgres://user:password@hostname:port/database
 * e.g.:
 *  postgres://u123:pabc@ec2.eu-west-1.compute.amazonaws.com:5432/dxyz
 */
$url = parse_url(getenv('DATABASE_URL'));
define('DB_HOST', $url['host']);
define('DB_NAME', substr($url['path'], 1)); // get rid of initial slash
define('DB_USER', $url['user']);
define('DB_PASSWORD', $url['pass']);

如果我这样做，我实际上是不尊重建议。由于变量， phpcs会理所当然地抱怨它：

FILE: config.php
-----------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------------
 1 | WARNING | A file should declare new symbols (classes, functions, constants, etc.) and cause no other side
   |         | effects, or it should execute logic with side effects, but should not do both. The first symbol
   |         | is defined on line 17 and the first side effect is on line 162.
-----------------------------------------------------------------------------------------------------------------

另一种选择是：

define('DB_HOST', parse_url(getenv('DATABASE_URL'))['host']);
define('DB_NAME', substr(parse_url(getenv('DATABASE_URL'))['path'], 1));
define('DB_USER', parse_url(getenv('DATABASE_URL'))['user']);
define('DB_PASSWORD', parse_url(getenv('DATABASE_URL'))['pass']);

没有变量，没有问题。但这是湿的，难以阅读。

我知道建议就是这样，它说“应该”，而不是“必须”。但这仍然困扰着我……一方面，任何时候我检查文件 phpcs 都会抱怨它，但每行只报告一次，从而为添加更多在配置文件中没有位置的“副作用”敞开大门。

我对整个 PSR 事情还是很陌生。

我是否错过了任何巧妙的方法来摆脱变量，同时保持可读性？

一个推论是：严肃的项目，坚持信守建议，如何处理这个问题？

4

2 回答 2

5

1.没关系，别出汗

你已经在你的问题中提到了它，但这个建议是应该而不是必须的。如果这是您整个项目中唯一的 PSR-1 问题：干得好！

但你的问题是：其他项目是如何进行的？

2. 远离配置的定义

全局常量，如果使用不当，是依赖磁铁。它们引入了耦合，使您的代码更难消化。这个问答很好地了解了为什么你应该远离它们。

改用依赖注入（是的，标量配置常量也是依赖）。

3. 案例研究：Symfony

基于Symfony的项目使用：

  • YAML（推荐）或 XML 配置文件来配置依赖注入容器，以及
  • environment variables，用于设置特定于应用程序运行的每个环境的配置选项。这些环境变量在特定于环境的 .env 文件中定义。

例如，要在 Symfony 项目中配置数据库服务，您需要创建一个 YAML 文件，其中包含：

services:
    My\Database\Factory: # <-- the class we are configuring
        arguments:
            $url: '%env(DATABASE_URL)' # <-- configure the $url constructor argument

Symfony 将其编译成 PHP 代码，将DATABASE_URL环境变量注入到需要它的类中。

DATABASE_URL然后，您将在类的构造函数中进行解析My\Database\Factory，并使用结果来构造您的数据库类。

优点：

  • 配置与代码分离
  • 配置易于更改
  • 配置易于阅读

缺点：

  • 依赖注入和使用 DI 容器有一个学习曲线，需要改变您对构造对象的看法。
于 2020-03-29T12:09:18.087 回答
1

正如十二因素应用程序方法中所述：

应用程序有时会将配置存储为代码中的常量。这违反了十二因素，要求严格分离配置与代码。配置因部署而异，但代码没有。

十二因素应用程序将配置存储在环境变量中。环境变量很容易在部署之间更改，而无需更改任何代码

您在最佳实践方面处于正确的轨道上，您只需要纠正一些错误。

1.环境变量使用变量

您想对不是的事物使用常量。数据库名称的值可能因环境而异。它不是一个常量，它是一个（环境）变量，你应该使用$dbName = getenv('DB_NAME').
相反，数字 π 是一个常数，它永远不会改变并且可以硬编码。

您可以查看 Composer 或 Symfony 组件等开源项目的源代码，您会看到getenv()仅用于填充变量。

2.直接使用配置中预期的元素

在您的情况下，您不应将完整的数据库 URL 用作单个配置项。相反，您应该按照配置的预期将环境变量中的每个元素分开，例如DB_HOST, DB_NAME, 。DB_PORT

于 2020-04-04T09:57:33.343 回答