服务中的许多依赖 [英] Many dependencies in service

问题描述

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

I have trouble with dependencies in my application in service layer.

我有以下课程:

   <?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.我的构造函数将再次增长.

There are only three dependencies which I'm injecting. Assume, I want to add next dependency, for example: NextService. My constructor will grow again.

如果我想在构造函数中传递更多的依赖关系怎么办?

What if I wanted to pass more dependencies within constructor ?

也许我应该通过传递IoC容器来解决此问题，然后获得所需的类?这是一个示例:

Maybe should I solve this problem by passing IoC container and then get desirable class? Here is an example:

<?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容器.

But now my UserService class depends on IoC container which I'm injecting.

如何遵循良好实践来解决问题?

How to solve a problem following good practices?

关于亚当

推荐答案

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

Injecting the container as a dependency to your service is considered as a bad practice for multiple reasons. I think the main point here is to figure out why and then try to understand the problem that leads you to think about "injecting the container" as a possible solution and how to solve this problem.

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

In object oriented programming, it's important to clearly define the relations between objects. When you're looking at a given object dependencies, it should be intuitive to understand how the object behaves and what are the other objects it relies on by looking at its public API.

在示例中，让您的对象依赖依赖解析器也是一个坏主意，在示例中您共享的对象没有 DI组件.如果要在其他地方使用该对象，例如在使用其他框架的应用程序中，则必须重新考虑对象获取其依赖项并对其进行重构的方式.

It's also a bad idea to let your object rely on a dependency resolver, In the example you shared your object can't live without the container which is provided by the DI component. If you want to use that object elsewhere, in an application that uses another framework for example, you'll then have to rethink the way your object get its dependencies and refactor it.

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

The main problem here is to understand why your service needs all these dependencies,

在面向对象编程中，

In object-oriented programming, the single responsibility principle states that every context (class, function, variable, etc.) should define a single responsibility, and that responsibility should be entirely encapsulated by the context. All its services should be narrowly aligned with that responsibility. Source: Wikipedia

基于此定义，我认为您应该将 UserService 划分为分别处理一个责任的服务.

Based on this definition, I think you should split your UserService into services that handle only one responsability each.

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

这篇关于服务中的许多依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！