在现代 mvc 架构中，控制器不应直接操作多个数据表或组合多个子控制器；正确做法是将跨模型的业务逻辑封装在独立的服务层（service layer）中，由控制器协调调用，确保职责分离与可测试性。
在现代 mvc 架构中，控制器不应直接操作多个数据表或组合多个子控制器；正确做法是将跨模型的业务逻辑封装在独立的服务层（service layer）中，由控制器协调调用，确保职责分离与可测试性。
当处理电商系统中的 Order 这类聚合根（Aggregate Root）时，它天然关联 orders、order_items、order_sellers、order_buyer 等多张表。初学者常误以为需为每张表创建独立控制器（如 OrderItemController），再由一个“复合控制器”（如 OrderController）手动实例化并编排它们——这种设计看似直观，实则严重违背 MVC 原则与分层架构思想。
❌ 为什么“组合控制器”是反模式？
- 控制器职责越界：MVC 中的 Controller 仅负责接收请求、调用业务逻辑、准备视图数据，不承担事务管理、数据组装或跨模型协调职责。
- 紧耦合与难测试：硬依赖多个控制器实例，导致单元测试需模拟整个控制流，违反单一职责原则。
- 破坏分层边界：控制器直连数据库逻辑（如 SQL JOIN），使表现层侵入基础设施细节，丧失架构可移植性（如切换 ORM 或迁移到微服务时重构成本极高）。
✅ 正确路径：引入服务层（Service Layer）与领域模型
应采用清晰的四层结构：
Request → Controller → Service (Use Case) → Domain Model → Data Mapper (Infrastructure)
- Controller：轻量级胶水，仅解析输入、调用服务、返回响应；
- Service（应用服务/用例）：实现完整业务用例（如 CreateOrderService），协调多个领域对象、管理事务、处理异常；
- Domain Model（领域模型）：定义 Order 聚合根及其内聚行为（如 Order::addItem()、Order::validate()），不依赖数据库或框架；
- Data Mapper（数据映射器）：唯一知晓 SQL 的组件，负责将 Order 对象映射到多表（支持 JOIN 查询），对上层完全透明。
? 示例：创建订单的服务层实现
以下代码展示如何通过服务层优雅处理多表写入：
// 应用服务：专注业务规则与协调
class CreateOrderService
{
public function __construct(
private OrderRepository $orderRepo,
private OrderItemRepository $itemRepo,
private BuyerRepository $buyerRepo,
private SellerRepository $sellerRepo,
private TransactionManager $tx
) {}
public function execute(array $input): Order
{
$this->tx->begin();
try {
// 1. 创建买家与卖家（可复用已有实体）
$buyer = $this->buyerRepo->findById($input['buyer_id']);
$seller = $this->sellerRepo->findById($input['seller_id']);
// 2. 构建订单聚合根（含校验）
$order = Order::create(
$buyer,
$seller,
new DateTime(),
$input['currency']
);
// 3. 添加明细项（聚合内强一致性）
foreach ($input['items'] as $itemData) {
$order->addItem(
$itemData['product_id'],
$itemData['quantity'],
$itemData['unit_price']
);
}
// 4. 持久化整个聚合（原子操作）
$this->orderRepo->save($order);
$this->tx->commit();
return $order;
} catch (\Exception $e) {
$this->tx->rollback();
throw $e;
}
}
}
// 控制器仅做请求-响应转换
class OrderController
{
public function __construct(private CreateOrderService $createOrderService) {}
public function create(Request $request): Response
{
$order = $this->createOrderService->execute($request->getParsedBody());
return new JsonResponse(['id' => $order->id()]);
}
}? 关键点：Order 类作为聚合根，封装了 order_items 的生命周期（如 addItem() 自动校验库存、计算总价），而 OrderRepository 的实现（如 PdoOrderRepository）内部可通过单条 JOIN 查询或事务批量插入完成多表持久化——上层服务完全无感。
⚠️ 注意事项与最佳实践
- 绝不让 Controller 依赖多个 Repository 或 Mapper：这会将数据访问逻辑泄露到表现层。
- 避免“贫血模型”：Order 不应只是 DTO，而应包含业务行为（如 Order::ship() 触发物流事件）。
- JOIN 查询属于 Data Mapper 层：例如 OrderRepository::findWithItems(int $id) 可在 PdoOrderRepository 中编写带 LEFT JOIN order_items 的 SQL，并将结果映射为完整 Order 对象。
- 事务边界由 Service 控制：Controller 不应开启/提交事务，确保业务用例的完整性。
- 依赖注入优先：所有协作对象（Repository、Service）均通过构造函数注入，便于替换与测试。
✅ 总结
构建“复合业务逻辑”的正确方式不是堆砌控制器，而是：
- 识别聚合根（如 Order）；
- 在 Service 层实现用例（如 CreateOrderService），协调领域对象与仓库；
- 将多表操作下沉至 Data Mapper，通过 SQL JOIN 或事务保证一致性；
- 保持 Controller 极简，只做协议适配（HTTP → Domain → HTTP）。
这种设计使系统具备高内聚、低耦合、易测试、可演进等关键特质——真正践行了 Martin Fowler 提出的 Service Layer 与 Domain Model 模式，而非停留在 CRUD 式的 MVC 表面理解。
