服务中的许多依赖项

Question

我在服务层的应用程序中遇到依赖性问题.

我有以下课程:

   <?php

class UserService{

    private $userRepository;
    private $vocationService;
    private $roleService;

    public function __construct(UserRepository $userRepository, VocationService $vocationService, RoleService $roleService)
    {
        $this->userRepository = $userRepository;
        $this->vocationService = $vocationService;
        $this->roleService = $roleService;
    }


} 

我正在注入的只有三个依赖项.假设,我想添加下一个依赖项,例如:NextService.我的构造函数会再次增长.

如果我想在构造函数中传递更多依赖项,该怎么办？

也许我应该通过传递IoC容器然后得到理想的类来解决这个问题？这是一个例子:

<?php

class UserService{

    private $userRepository;
    private $vocationService;
    private $roleService;

    public function __construct(ContainerInterface $container)
    {
        $this->userRepository = $container->get('userRepo');
        $this->vocationService = $container->get('vocService');
        $this->roleService = $container->get('roleService');
    }

} 

但现在我的UserService类依赖于我注入的IoC容器.

如何通过良好实践解决问题？

问候,亚当

Answer 1

出于多种原因,将容器注入作为服务的依赖项被视为不良做法.我认为这里的要点是找出原因,然后尝试理解导致您将"注入容器"作为可能的解决方案以及如何解决此问题的问题.

在面向对象的编程中,清楚地定义对象之间的关系很重要.当您查看给定的对象依赖项时,应该直观地了解对象的行为方式以及通过查看其公共API所依赖的其他对象.

让你的对象依赖依赖性解析器也是一个坏主意.在你共享的例子中你的对象不能没有DI组件container提供的对象.如果要在其他地方使用该对象,例如在使用其他框架的应用程序中,则必须重新考虑对象获取其依赖关系并重构它的方式.

这里的主要问题是理解为什么您的服务需要所有这些依赖项,

在面向对象的编程中,单一责任原则 规定每个上下文(类,函数,变量等)应该定义单个责任,并且该责任应该完全由上下文封装.其所有服务应与该责任严格一致.资料来源:维基百科

根据这个定义,我认为你应该将你的UserService服务分成只处理一个责任的服务.

• 例如,获取用户并将其保存到dababase的服务
• 另一种管理角色的服务
• ... 等等