ZF2：将特定于操作的配置注入控制器

Question

至少有三种方法——Zend\Di、ConfigAwareInterface 和ControllerFactory——我考虑过将配置注入控制器。

导致此代码的more or less official recommendation is the ControllerFactory（或this code if you prefer closures——我不知道，因为它们更难测试）：

// module.config.php
'controllers' => array (
    'factories' => array (
        'Module\Concept\Index' => 'Concept\ControllerFactory\IndexControllerFactory',
    ),
),
'some_config_key' => array (
    'x' => 'foo'
),

// src/Concept/ControllerFactory/IndexControllerFactory.php
class IndexControllerFactory implements FactoryInterface {
    public function createService(ServiceLocatorInterface $serviceLocator) {
        $config = $serviceLocator->getServiceLocator()->get('config');
        $controller = new \Html\Controller\IndexController($config['some_config_key']);
        return $controller;
    }
}

// src/Concept/Controller/IndexController.php
class IndexController {
    public function __construct($config) {
        // here we go, yay!  we have $config['x'] == 'foo'
    }
}

如果每个操作都需要不同的配置（例如，一个可能需要 DB，另一个可能需要 paypal），当只有 一些 时传递 all 控制器配置似乎不合适> 行动所需要的。

那么，哪些操作需要哪些配置的知识应该进入工厂还是控制器？也就是说，工厂应该根据手头的动作只给控制器它需要的东西，还是应该给控制器所有的配置并在内部弄清楚？

更新
特定于操作的依赖关系就是：特定的。控制器声明它需要什么，然后以任何必要的方式使用它。这两个动作的需求完全不同，这表明控制器的范围可能过于宽泛，并且可能是分离的候选者。

但无论如何，最好的方式——清晰、稳健且显然符合 ZF 未来方向的方式——是在服务工厂制造所需的服务，然后制造具有必要服务的控制器。

两个工厂：服务和控制器。控制器用它必须拥有的服务声明其__construct 合同，然后工厂根据模块配置根据需要制造这些服务。

Answer 1

这个问题主要是基于意见的，所以你可以得到很多不同的答案。

这两种方法都很好，因为：

• 如您所知，我们在 ZF2 中经常看到的是服务管理器，所有合并的配置都在所有应用程序周围运行。因此，即使这不是最好的方法，它也被广泛使用。
• 如果我们牢记依赖倒置原则（我们确实有）以及high cohesion 和low coupling 原则，这告诉我们隔离是好的，所有组件不必知道两个很多关于其他的，并且模块内的所有内容都应该是强相关的，我们可以认为在每个控制器中都有所有合并的配置，甚至让控制器知道关联的合并配置数组中的哪个键包含它的配置，可能不是最好的东西，也许一个模块应该接收的是它的配置，无论它来自更大的数组，来自工厂，来自地狱，还是来自其他地方，因为事实上，它不需要知道，这并不重要。

所以最好的方法可能是只注入它所期望的配置。实际上，这就是我们在创建 ViewHelper 时所做的事情，通常我们不会注入所有东西，而只注入我们需要的东西。

这可能会令人困惑，因为有时您可能还需要一些其他通用配置，而不仅仅是纯粹与模块相关的配置，在这种情况下您将不得不考虑它。但在大多数情况下，更优雅的解决方案可能是注入你需要的东西。

作为另一个重要的论点，我在sam minds blog 中读到

...还有几件事 只是不理想。一个小例子就是很多人使用 $this->getServiceLocator() 在他们的控制器中。虽然这没问题， 这实际上被认为是不好的做法。事情的样子 目前，此功能将在 Zend Framework 3 (ZF3) 中删除以 基本上强迫人们使用正确的依赖注入 服务管理器。

所以我们可以认为，正确的方法是尽可能地引入依赖注入，并尽可能少地让每个组件知道。