面向对象PHP中优雅获取POST请求的方案及SOLID合规性探讨

假设有如下HTML表单：

<form action="Controller.php" method="post">
    <input type="text" name="product" placeholder="product">
    <input type="number" name="price" placeholder="price">

    <button type="submit">send</button>
</form>

在PHP开发中，常见的做法是直接在控制器类的构造函数里通过$_POST全局变量初始化属性，示例代码如下：

<?php
class ControllerProduct
{
    private $product;
    private $price;

    public function __construct()
    {
        $this->product = $_POST['product'];
        $this->price   = $_POST['price'];
    }
}
?>

但这种写法存在明显弊端：类直接耦合了$_POST这个全局数据来源，是否违反SOLID原则？有没有符合清洁开发标准的优化方式？

1. 用依赖注入解耦数据来源 #

把请求数据作为参数传入构造函数，而非直接依赖全局变量。这样控制器不需要关心数据到底来自$_POST、$_GET还是测试模拟数据，完全符合依赖倒置原则和单一职责原则：

<?php
class ControllerProduct
{
    private $product;
    private $price;

    public function __construct(string $product, float $price)
    {
        $this->product = $product;
        $this->price = $price;
    }
}

// 在控制器外部处理请求数据，再注入实例
$controller = new ControllerProduct(
    $_POST['product'],
    (float)$_POST['price']
);
?>

2. 用DTO封装请求数据 #

如果请求参数较多，推荐用**数据传输对象（DTO）**统一封装请求数据，让控制器只依赖DTO，进一步降低耦合度，同时还能把数据验证逻辑放到DTO里：

<?php
// 定义请求DTO，负责封装和验证输入数据
class ProductRequest
{
    public string $product;
    public float $price;

    public function __construct(array $data)
    {
        // 这里加入输入验证逻辑
        if (empty($data['product'])) {
            throw new InvalidArgumentException('产品名称不能为空');
        }
        if (!isset($data['price']) || !is_numeric($data['price'])) {
            throw new InvalidArgumentException('价格必须是有效数字');
        }

        $this->product = $data['product'];
        $this->price = (float)$data['price'];
    }
}

// 控制器只依赖DTO，无需关心数据来源
class ControllerProduct
{
    private $product;
    private $price;

    public function __construct(ProductRequest $request)
    {
        $this->product = $request->product;
        $this->price = $request->price;
    }
}

// 外部实例化DTO并注入控制器
$request = new ProductRequest($_POST);
$controller = new ControllerProduct($request);
?>

3. 分离输入验证与控制器逻辑 #

把输入验证、数据过滤的逻辑完全从控制器中抽离，让控制器只专注于业务逻辑处理，严格遵循单一职责原则。除了用DTO承担验证职责，也可以单独写一个验证器类：

<?php
class ProductValidator
{
    public static function validate(array $data): array
    {
        $errors = [];
        if (empty($data['product'])) {
            $errors[] = '产品名称不能为空';
        }
        if (!isset($data['price']) || !is_numeric($data['price']) || $data['price'] <= 0) {
            $errors[] = '价格必须是正数';
        }

        if (!empty($errors)) {
            throw new InvalidArgumentException(implode(', ', $errors));
        }

        // 返回过滤后的合法数据
        return [
            'product' => $data['product'],
            'price' => (float)$data['price']
        ];
    }
}

// 控制器仅处理业务逻辑
class ControllerProduct
{
    private $product;
    private $price;

    public function __construct(string $product, float $price)
    {
        $this->product = $product;
        $this->price = $price;
    }

    public function handle()
    {
        // 这里写具体业务逻辑，比如保存到数据库
    }
}

// 外部执行流程：验证数据 → 注入控制器 → 处理业务
$validatedData = ProductValidator::validate($_POST);
$controller = new ControllerProduct(
    $validatedData['product'],
    $validatedData['price']
);
$controller->handle();
?>

原写法违反SOLID的原因 #

原写法直接在构造函数中使用$_POST，违反了3条核心SOLID原则：

• 单一职责原则：控制器既要处理业务逻辑，又要负责请求数据的获取，职责混杂。
• 依赖倒置原则：依赖了具体的全局变量（$_POST），而非抽象的数据源，单元测试时无法模拟请求数据，扩展性差。
• 开闭原则：如果后续需要支持GET请求、JSON接口等其他数据源，必须修改控制器的构造函数，不符合“对扩展开放、对修改关闭”的要求。

内容的提问来源于stack exchange，提问作者SidSan