CodeIgniter 4为何不建议在模型与库中直接使用Services？

虽然直接调用Services::xxx()看起来更简便，但官方的建议其实是从可维护性、可测试性和代码架构合理性出发的，核心原因有这几点：

• 依赖关系不透明
  直接调用Services会把依赖藏在代码内部，其他开发者（甚至一段时间后的你）查看模型/库的接口时，根本不知道它依赖了哪些服务。你得逐行翻代码才能找出所有依赖，维护成本直线上升。而通过构造函数或setter注入，依赖明明白白写在参数里，一眼就能看清楚。

• 单元测试寸步难行
  单元测试的核心是隔离依赖，要是模型里硬编码调用Services，你没法替换成模拟（Mock）实例。比如测试一个操作数据库的模型，你总不能每次测试都连真实数据库吧？用构造注入的话，测试时只需要传一个模拟的数据库连接进去，就能单独验证模型的业务逻辑，不用依赖真实服务。

• 代码耦合度太高
  直接调用Services会让你的模型/库和框架的服务容器强绑定。哪天你想换个容器实现，或者修改某个服务的初始化逻辑，所有直接调用的地方都得挨个改。而注入式的写法，只需要在控制器层面调整服务的获取方式，模型/库的代码完全不用动，符合开闭原则。

• 违反单一职责原则
  模型的本职工作是处理数据逻辑，库是封装特定业务能力，它们不该承担“获取依赖”的额外职责。直接调用Services会让这些类的职责变得混乱，既管业务逻辑，又管依赖查找，后续扩展和修改都容易出问题。

反面示例（直接调用Services） #

class UserModel extends Model
{
    public function getActiveUsers()
    {
        // 依赖隐藏在内部，外部无法感知
        $db = Services::db();
        return $db->table('users')->where('is_active', 1)->get()->getResult();
    }
}

正面示例（构造函数注入） #

class UserModel extends Model
{
    private $db;

    // 依赖明确声明在构造函数参数中
    public function __construct(\CodeIgniter\Database\BaseConnection $db)
    {
        parent::__construct();
        $this->db = $db;
    }

    public function getActiveUsers()
    {
        return $this->db->table('users')->where('is_active', 1)->get()->getResult();
    }
}

控制器中注入服务：

class UserController extends BaseController
{
    public function index()
    {
        $db = Services::db();
        $userModel = new UserModel($db);
        $activeUsers = $userModel->getActiveUsers();
        
        return view('users/list', ['users' => $activeUsers]);
    }
}

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