如何避免PHP中Service类与Model类的隐式依赖

问题背景 #

我采用的架构依赖流转为：Handler类 ↔ Service类 ↔ Mapper类 ↔ Model类，规则是各层仅显式依赖相邻层，修改某层仅影响直接相邻的两层。但目前存在不良实践：Service调用Mapper方法后，直接调用返回的Model实例的方法，形成Service与Model的直接隐式依赖，打破了分层边界。

我提出的现有思路及痛点 #

1. 向Service注入空Model实例显式声明依赖：操作繁琐，且无法适配多记录结果集
2. Mapper返回Model接口+\Iterable：多结果集场景下用\Iterable避免O(2n)的时间复杂度，但仍存在隐式依赖；尝试过想类似int[]的方式声明\Iterable的元素类型，考虑过创建Model专属自定义Iterator，但不确定是否为最优方案

业界常用解决方案及分析 #

1. 数据传输对象（DTO）隔离法（业界主流首选） #

核心思路是：让Mapper层负责将Model转换为Service专用的DTO（数据传输对象），Service仅依赖DTO的接口，完全不感知Model的存在。

实现示例

首先定义DTO接口与实现：

// 定义DTO接口，Service仅依赖此接口
interface UserDtoInterface {
    public function getName(): string;
}

// DTO具体实现，仅包含Service需要的数据与方法
class UserDto implements UserDtoInterface {
    private string $name;

    public function __construct(string $name) {
        $this->name = $name;
    }

    public function getName(): string {
        return $this->name;
    }
}

修改Mapper层，用生成器将Model转换为DTO返回（无需预遍历集合，保持O(n)时间复杂度）：

namespace App\Mapper;

class Mapper implements MapperInterface 
{
    protected ModelInterface $modelPrototype;

    public function __construct(ModelInterface $model){
        $this->modelPrototype = $model;
    }

    public function getAllRows(): \Iterable<UserDtoInterface> {
        // 执行SQL并填充Model实例的逻辑
        $modelResultSet = $this->executeQueryAndHydrateModels();
        
        // 生成器实时转换，避免额外循环
        foreach ($modelResultSet as $model) {
            yield new UserDto($model->getName());
        }
    }
}

修改Service层，仅依赖DTO接口：

namespace App\Service;

class Service implements ServiceInterface 
{
    protected MapperInterface $mapper;

    public function __construct(MapperInterface $mapper){
        $this->mapper = $mapper;
    }

    public function getAllRows() {
        foreach ($this->mapper->getAllRows() as $userDto) {
            $name = $userDto->getName();
            // 业务逻辑处理
        }
    }
}

优势

• 彻底隔离Service与Model，修改Model的结构或方法完全不会影响Service层
• 多结果集场景下用生成器保持O(n)时间复杂度，无性能损耗
• 符合依赖倒置原则，Service依赖抽象的DTO接口而非具体实现

2. 泛型声明Iterable元素类型（低成本方案） #

PHP 8.1及以上版本支持泛型，可直接在Mapper接口中声明\Iterable的元素类型为ModelInterface，将隐式依赖转为显式依赖，同时无需额外循环。

实现示例

修改Mapper接口：

interface MapperInterface {
    public function getAllRows(): \Iterable<ModelInterface>;
}

此时Service迭代时，静态分析工具（如PHPStan、Psalm）会明确识别迭代元素为ModelInterface类型，依赖关系从隐式变为显式，符合分层规则（Service依赖抽象的Model接口，而非具体Model类，且依赖通过Mapper传递）。

优势

• 代码改动极小，成本低
• 保留原有架构逻辑，无需引入新的DTO层
• 静态分析可确保类型安全，避免隐式依赖带来的维护问题

3. Mapper层封装数据提取逻辑（极简方案） #

将Service需要的数据提取逻辑封装到Mapper层，Service直接获取加工后的原始数据，完全不接触Model或DTO。例如，若Service仅需要所有行的名称，可让Mapper新增getAllRowNames()方法，直接返回\Iterable<string>。

实现示例

// Mapper类新增方法
public function getAllRowNames(): \Iterable<string> {
    $modelResultSet = $this->executeQueryAndHydrateModels();
    foreach ($modelResultSet as $model) {
        yield $model->getName();
    }
}

// Service调用
public function getAllRows() {
    foreach ($this->mapper->getAllRowNames() as $name) {
        // 业务逻辑处理
    }
}

优势

• Service逻辑极简，完全脱离数据层实现细节
• 无额外抽象层开销

缺点

• 若Service需要多个字段，会导致Mapper方法数量膨胀，仅适合简单业务场景

关于自定义Model专属Iterator的方案 #

自定义Iterator确实能实现元素类型约束，但属于过度设计。泛型+\Iterable已经能满足类型安全需求，而DTO方案才是彻底隔离依赖的业界主流选择，自定义Iterator的收益远小于成本。

方案优先级推荐 #

1. DTO方案：彻底隔离依赖，符合分层架构设计原则，适合大多数复杂业务场景
2. 泛型+Iterable方案：低成本解决隐式依赖问题，适合追求简洁、无需彻底隔离的场景
3. Mapper数据提取方案：适合简单业务逻辑，避免过度抽象

内容的提问来源于stack exchange，提问作者d.lanza38