在Slim框架中将$app实例存入容器是否属于不良实践？

把Slim的$app实例存入容器本身不属于致命错误，但确实是不符合依赖注入最佳实践的实现，会带来后续维护、测试层面的隐患。

• 依赖不透明，违背DI设计初衷：你在抽象类中注入整个容器，再从容器中取$app的做法属于服务定位器模式，所有子类的依赖都不会显式声明在构造函数中，其他开发者读代码时无法直接知道类的依赖项，单元测试时也需要模拟整个容器，而非仅模拟所需的依赖对象，测试成本大幅提升。
• 业务层与框架过度耦合：你的业务服务类直接依赖整个Slim App实例，等于把业务逻辑和Slim框架深度绑定，后续如果需要升级Slim大版本、甚至换其他框架开发，所有继承该抽象类的业务代码都需要重构，完全没有可迁移性。
• 存在循环依赖隐患：Slim的App实例本身已经依赖容器，你再把App存入容器，虽然当前版本可以正常运行，但后续如果容器实例化逻辑调整，很容易触发循环依赖问题，排查成本极高。

你想要的「无需手动传参即可让子类获取公共依赖」的需求完全可以通过显式依赖注入实现，不需要借助容器和App实例：

1. 抽象类直接声明公共依赖，不要注入整个容器或App，你业务中需要的路由、响应工厂、请求解析器等能力，都可以直接注入Slim提供的对应接口，不需要拿到整个App实例。示例代码如下：

<?php
declare(strict_types=1);

namespace Testing;

use Slim\Interfaces\RouteCollectorInterface;
use Psr\Http\Message\ResponseFactoryInterface;

abstract class Service
{
    // 仅声明需要用到的公共依赖，不要整容器、整App
    protected RouteCollectorInterface $router;
    protected ResponseFactoryInterface $responseFactory;

    public function __construct(
        RouteCollectorInterface $router,
        ResponseFactoryInterface $responseFactory
    ) {
        $this->router = $router;
        $this->responseFactory = $responseFactory;
    }
}

2. 子类无需额外修改构造函数传参逻辑，Slim的DI容器会自动解析构造函数的依赖项，你依然可以用$serviceExample = $container->get(ServiceExample::class);的方式实例化子类，完全符合你的使用习惯。
3. 如果确实有极特殊场景必须用到App实例，建议单独封装一层框架适配层处理和App相关的操作，不要让业务服务直接依赖App，把业务逻辑和框架能力隔离开。

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