ServiceLocator，让我们在ZF2环境中思考一下

Question

根据马可·皮维塔的想法，这个老问题和我对另一个问题的回答

我在询问自己如何更好地在Zend Framework 2应用程序中使用我们的服务。

实际上，我们可以将ServiceLocatorAware Interface与ServiceLocatorAware Trait结合使用。事实上，在ZF3中，服务定位器将在控制器中被删除。他们可能也会删除这个接口，或者建议人们不要使用它，这是有意义的。

我认为构建我们的服务的唯一方式是:

不要在您的服务中使用ServiceLocator，请使用Dependancy注入。

问题是 __________：

有些项目是如此之大，以至于你有：

• 一个工作流的 15 个服务的类。
• 具有 15 个依赖项的服务类。
• 选择你的噩梦...

您在服务中可能需要的一些示例：

• 取回formManager（不能在控制器中调用它）
• 在通过AJAX和JSON响应将超文本标记语言字符串返回视图之前，您可能需要让ViewRenader渲染模板；
• 您可能需要取回ZF2提供的翻译或您想要的所有服务
• 获取您的实体管理器，如果您有多个数据库，请在此处添加count
• 获取其他服务，如邮件服务、导出服务、导入服务等…
• 如果您必须加载特定服务，则取决于客户端（BtoB中的多客户端网站…添加一些服务，因为您无法加载|调用AbstractFactory）

也许对于其中的一些点，它们可以通过一个我不知道的技巧来解决。

我的问题是:

为一个服务提供 15 个或更多依赖项并放弃服务定位器（在控制器中，以及在服务中）是否是一种很好的做法？

从评论编辑

为了说明我的观点，我粘贴了我的一个构造函数：

public function __construct(
    ToolboxService $toolboxService,
    EntityService $entityService,
    UserService $userService,
    ItemService $itemService,
    CriteriaService $criteriaService,
    Import $import,
    Export $export,
    PhpRenderer $renderer
) {
    $this->toolboxService = $toolboxService;
    $this->entityService = $entityService;
    $this->userService = $userService;
    $this->emOld = $this->toolboxService->getEmOld();
    $this->emNew = $this->toolboxService->getEmNew();
    $this->serviceLocator = $this->toolboxService->getServiceLocator();
    $this->itemService = $itemService;
    $this->criteriaService = $criteriaService;
    $this->import = $import;
    $this->export = $export;
    $this->renderer = $renderer;
    $this->formManager = $this->toolboxService->getFormManager();
}

如您所见，工具箱服务是一个具有多个依赖项的对象。此服务位于我的“应用程序”文件夹中，几乎无处不在。我有2个实体管理器（连接到2个数据库，但也许很快，我需要第三个...）

您可以看到，我通过依赖关系使用serviceLocator，因此该服务不实现ServiceLocatorAwareInterface。如果我不使用它，我会为我的AbstractFactory电话

// Distribute somes orders depends on Clients
$distributionClass = $this->serviceLocator->get(ucfirst($param->type));
            if ($distributionClass instanceof DistributeInterface) {
                $distributionClass->distribute($orders, $key);
            } else {
                throw new \RuntimeException("invalid_type_provided", 1);
            }

Answer 1

假设您将注入ServiceLocator实例。不能保证ServiceLocator实际上保存了您的硬依赖项，从而打破了DI模式。当使用构造函数依赖注入时，您可以确保所需的所有服务都确实可用。否则，服务的构造将失败。

使用服务定位器时，您最终将进入一个实例化的服务类，其中硬依赖项可能通过服务定位器提供，也可能不可用。这意味着您必须编写所有类型的附加逻辑（检查依赖项，抛出异常），以防依赖项无法在您请求时从 ServiceLocator 实例解析。编写所有这些代码可能会比注入 15 个依赖项要多得多，最重要的是，逻辑将在整个服务中变得混乱。

此外，您还需要添加所有的setter和getter方法，以便能够从< code>ServiceLocator获取您的服务，并使您的服务可测试。

IMHO注入15个依赖项的代码比注入ServiceLocator实例更少，更容易维护。