在现代mvc架构中，控制器不应直接操作多个数据表或组合多个子控制器；正确的做法是将跨表业务逻辑封装在独立的服务层（如orderservice），由控制器仅负责协调请求与响应，而数据访问则严格委托给数据映射器（data mapper）。
在现代mvc架构中，控制器不应直接操作多个数据表或组合多个子控制器；正确的做法是将跨表业务逻辑封装在独立的服务层（如orderservice），由控制器仅负责协调请求与响应，而数据访问则严格委托给数据映射器（data mapper）。
当处理像电商订单（Order）这样天然聚合多张表（orders、order_items、order_sellers、order_buyer等）的业务实体时，初学者常倾向于设计一个“复合控制器”——例如 OrderController 内部持有 OrderInfoController、OrderItemController 等多个控制器实例，并在 create()、get() 等方法中依次调用它们。这种做法看似直观，实则严重违背分层架构原则，会导致控制器职责膨胀、测试困难、数据库耦合加剧，且难以应对事务一致性、并发控制和领域规则校验等核心需求。
✅ 正确的架构路径是职责分离 + 分层抽象：
- 控制器（Controller）：仅解析HTTP请求、校验基础输入（如参数格式）、调用服务层、返回响应。它不包含SQL、不操作模型对象、不管理事务。
- 应用服务层（Application Service / Use Case）：例如 OrderService，是业务逻辑的真正承载者。它协调多个领域对象（如 Order、OrderItem）、调用多个仓储（Repository）或集合（Collection），并包裹完整事务。这是实现“创建一个订单及其全部子项”的唯一合理位置。
- 领域模型层（Domain Model）：定义业务本质，如 Order 实体类应内聚地管理其状态（如总金额计算、库存预占校验）、生命周期规则（如“已支付订单不可修改收货地址”）。它完全 unaware of数据库、HTTP 或框架。
- 基础设施层（Infrastructure）：仅在此处出现具体技术细节。OrderDataMapper 或 OrderRepository 的实现类（如 PdoOrderMapper）负责执行 JOIN 查询、批量插入、事务提交等，且可自由使用任意 SQL（包括跨表关联查询），但对外仅暴露领域接口。
以下是一个精简但生产就绪的 OrderService 示例，展示如何安全、清晰地封装复合操作：
<?php
namespace App\Service\Order;
use App\Domain\Model\Order\Order;
use App\Domain\Model\Order\OrderCollection;
use App\Domain\Model\Order\OrderItem;
use App\Domain\Model\Order\OrderItemCollection;
use App\Domain\Infrastructure\Mapper\Order\OrderMapper;
use App\Domain\Infrastructure\Mapper\Order\OrderItemMapper;
class OrderService
{
public function __construct(
private OrderCollection $orderCollection,
private OrderItemCollection $orderItemCollection,
private OrderMapper $orderMapper,
private OrderItemMapper $orderItemMapper
) {}
/**
* 创建完整订单（含主单 + 多个商品项），保证原子性
*/
public function createOrder(array $data): Order
{
// 1. 启动事务（通常在基础设施层或服务调用前由AOP/中间件管理）
$this->orderMapper->beginTransaction();
try {
// 2. 构建领域对象
$order = new Order();
$order->setBuyerId($data['buyer_id']);
$order->setStatus('pending');
// 3. 持久化主订单，获取生成ID
$order = $this->orderMapper->save($order);
// 4. 批量创建订单项
foreach ($data['items'] as $itemData) {
$item = new OrderItem();
$item->setOrderId($order->getId());
$item->setProductId($itemData['product_id']);
$item->setQuantity($itemData['quantity']);
$item->setPrice($itemData['price']);
$this->orderItemMapper->save($item);
}
// 5. 提交事务
$this->orderMapper->commit();
return $order;
} catch (\Throwable $e) {
$this->orderMapper->rollback();
throw $e;
}
}
/**
* 获取完整订单详情（单次JOIN查询，非N+1）
*/
public function findOrderWithItems(int $orderId): ?array
{
return $this->orderMapper->fetchOrderWithItems($orderId);
// SQL示例: SELECT o.*, oi.* FROM orders o JOIN order_items oi ON o.id = oi.order_id WHERE o.id = ?
}
}? 关键注意事项与最佳实践：
- 禁止控制器持有其他控制器：控制器是请求入口点，不是业务协调器。让 OrderController 依赖 OrderService，而非 OrderItemController。
- JOIN 查询应在 Data Mapper 中完成：如上例中 fetchOrderWithItems() 方法，由 OrderMapper 封装复杂SQL，返回结构化数组或DTO，避免在服务层拼接N+1查询。
- 事务边界由服务层定义，由基础设施层执行：OrderService::createOrder() 明确表达了“整体成功或整体失败”的业务契约，而 beginTransaction()/commit()/rollback() 应在 OrderMapper 等基础设施组件中实现（如基于PDO或ORM事务API）。
- 领域模型保持纯净：Order 类不应有 save() 方法，也不应引用 $pdo 或 OrderItemController —— 它只表达业务规则，如 public function canCancel(): bool { return $this->status === 'pending'; }。
- 可测试性优先：由于 OrderService 仅依赖接口（OrderCollection、OrderMapper），可轻松注入 Mock 对象进行单元测试，无需启动数据库。
总结而言，面对多表聚合的业务场景，真正的“复合控制器”并不存在；取而代之的是一个高内聚的服务类，它站在领域视角编排逻辑，通过清晰的接口与下层协作。这种设计不仅解决了订单这类复杂实体的CRUD问题，更奠定了系统可维护、可扩展、可演进的坚实基础。
