Slim框架中基于多租户的动态路由控制器解决方案

背景介绍

在Slim框架开发多租户系统时，我们经常需要根据不同的域名(hostname)来提供差异化的功能和界面。本文探讨了在Slim4框架下实现这一需求的几种技术方案，特别关注如何优雅地处理不同租户间的控制器逻辑差异。

传统中间件方案

最常见的实现方式是使用中间件来识别租户：

final class SiteSelectorMiddleware implements MiddlewareInterface {
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface {
        $host = $request->getUri()->getHost();
        $request = $request->withAttribute('host', $host);
        // 其他租户特定处理逻辑
        return $handler->handle($request);
    }
}

这种方案可以很好地处理模板、样式等资源的差异化配置，但当需要修改控制器核心逻辑时，开发者往往需要在控制器中加入大量条件判断：

class MyAction {
    public function get(ServerRequestInterface $request, ResponseInterface $response): ResponseInterface {
        if($host == "variantsite") {
            // 租户A特定逻辑
        } else {
            // 默认逻辑
        }
    }
}

继承方案探索

为了避免控制器中的条件分支，开发者提出了基于类继承的方案：

1. 定义基础控制器类

class MyAction {
    public function get(ServerRequestInterface $request, ResponseInterface $response): ResponseInterface {
        // 标准实现
        return $this->render($response, 'home.twig', []);
    }
}

2. 为特定租户创建子类

class SubClassMyAction extends MyAction {
    public function get(ServerRequestInterface $request, ResponseInterface $response): ResponseInterface {
        // 定制逻辑
        return parent::get($request, $response);
    }
}

3. 动态修改路由调用

$route = $app->getRouteCollector()->getNamedRoute($routeName);
$route->setCallable(SubClassMyAction::class. ':home');

更优的服务层方案

虽然继承方案可行，但更符合SOLID原则的做法是将业务逻辑移至服务层：

1. 控制器保持精简

final class MyAction {
    private EventLister $eventLister;
    
    public function __construct(EventLister $eventLister) {
        $this->eventLister = $eventLister;
    }
    
    public function post(ServerRequestInterface $request, ResponseInterface $response): ResponseInterface {
        $host = $request->getAttribute('host') ?? '';
        $events = $this->eventLister->getPublishedEvents($host);
        return $this->render($response, 'events.twig', $events);
    }
}

2. 服务类处理业务逻辑

final class EventLister {
    private EventListerRepository $repository;
    
    public function __construct(EventListerRepository $repository) {
        $this->repository = $repository;
    }
    
    public function getPublishedEvents(string $host): array {
        // 输入验证
        // 租户特定逻辑处理
        return $this->repository->fetchPublishedEvents($host);
    }
}

方案对比

方案	优点	缺点
中间件+条件判断	实现简单，适合简单差异	控制器臃肿，维护困难
类继承+动态路由	逻辑分离清晰	破坏路由缓存，框架非原生支持
服务层方案	符合SOLID原则，易于测试	需要重构现有代码

最佳实践建议

1. 对于UI层面的差异（样式、模板），优先使用中间件方案
2. 对于简单的业务逻辑差异，可以采用服务层方案
3. 只有在极端情况下（完全不同的业务流程）才考虑继承方案
4. 保持控制器精简，将业务逻辑移至服务层
5. 考虑使用策略模式来处理不同租户的业务规则差异

通过合理分层设计，可以在保持代码整洁的同时满足多租户系统的差异化需求。