使用 IoC 容器的 OOD - 如何构造依赖对象？

Question

我正在努力改进 IoC、DI 和 OOD，以获得更好的可测试性和更松散的耦合。

因此，当我们设计大量使用 IoC 和 DI 的类时，我们最终可能会得到具有多个依赖项的类，例如

class Processor
{
    private IService1 m_Service1;
    private IService2 m_Service2;
    private IService3 m_Service3;

    //approach 1 
    public Processor(IService1 service1, IService2 service2, IService3 service3)
    {
        m_Service1 = service1;
        m_Service2 = service2;
        m_Service3 = service3;
    }
    //approach 2
    public Processor(IContainer container)
    {
        m_Service1 = container.Resolve<IService1>();
        m_Service2 = container.Resolve<IService2>();
        m_Service3 = container.Resolve<IService3>();
    }

    //approach 3
    public delegate Processor Factory();

}

我在想这里通常的方法应该是什么。我们可以让构造函数保留 3 个参数，但是如果我们使用 autofac 构建应用程序（例如），很可能除了解析某些容器实例的类型之外，它很少会被使用，

    Processor proc = new Processor(
 container.Resolve<IService1>(),
 container.Resolve<IService2>(),
 container.Resolve<IService3>());

所以我想当我们依赖时，方法 2 可能更好容器中的多种类型。无论如何，我们必须在某处添加对 autofac 的引用，那么现在有什么理由不这样做呢？

Autofac 还提供委托工厂方法方法

http://code.google.com/p/autofac/ wiki/DelegateFactories

var processorFactory = container.Resolve<Processor.Factory>();
Processor processor = processorFactory.Invoke();

因此，我们还有方法 3 - 我们不会使用构造函数来创建类实例，而是从容器中调用已解析的委托，它将为我们解析依赖项。

由于我对 IoC 相当陌生，很难说我们什么时候应该使用 1、2、3。它们各有优点和缺点。

我认为一般来说，如果类有 1 个依赖项，我们可能总是可以使用方法 1.. 除此之外，我真的不确定选择什么以及何时选择。

更新 我已经阅读了有关服务定位器反模式的内容，但我想出了第四种（或真正的第三种方法），

它接近 ServiceLocator，但它不是，我们传递一个看起来像这样的对象

public class ServiceLocatorObject
{
        private IService1 m_Service1;
        private IService2 m_Service2;
        private IService3 m_Service3;
        public IService1 Service1 {get {return m_Service1;}}
        public IService2 Service2 {get {return m_Service2;}}
        public IService3 Service3 {get {return m_Service3;}}

        public ServiceLocatorObject(IService1 service1, IService2 service2, IService3 service3)
        {
            m_Service1 = service1;
            m_Service2 = service2;
            m_Service3 = service3;
        }
}

现在我们创建

//approach 4
public Processor(ServiceLocatorObject servicesToUse)
{
    m_Services = servicesToUse;
}

现在我们已经将我们的类与服务实现解耦，并且很清楚它需要什么真正的依赖项（如果我们假设传递的对象上可用的所有服务都是必需的），因为我们没有传递可以包含 100 个实现的容器。如果我们的应用程序中的另一个类可能需要这 3 个服务组合，那么该对象甚至可以重用。所以我们使用构造函数 DI 而不是 ServiceLocator 模式。接口清晰并且没有过多的依赖项，新类可能是一个很好的重用候选者。

对于这个你有什么想说的呢？

Answer 1

如今，服务位置模式通常被认为是反模式（使用container.Resolve并注入容器）。

在我自己对这个概念进行了一番挣扎并试图决定我喜欢它还是讨厌它之后，我个人意识到我同意服务位置是一种反模式 - 因为它混淆了存在的相互依赖关系，而这些相互依赖关系是核心面向对象编程的概念。

在这里阅读：
http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

我实际上喜欢这样一个事实：在选项 1 中，Process 清楚地表达了它对其列出的每个服务的依赖关系：构造函数中的参数。它使依赖性非常明显......而且我认为它有助于促进良好的设计。

仅仅说 Processor 采用 IContainer 并不能告诉我们太多信息......因此您需要更仔细地查看以识别相互依赖关系。

Answer 2

JeffN825 给出的答案是正确的，但我想补充一点，您永远不会使用这样的容器创建新的处理器实例：

Processor proc = new Processor(
    container.Resolve<IService1>(),
    container.Resolve<IService2>(),
    container.Resolve<IService3>());

相反，您应该让容器自动装配 依赖项并解决它去：

Processor proc = container.Resolve<Processor>();

Answer 3

这与依赖项的数量无关，也与每个类的决定无关。方法 2 引入了新的依赖项，但如果您想依赖 IoC 容器，那么这是一个很好的方法。方法 3 与第二种类似，但是让您将来在工厂中做一些事情。方法 1 最简单，不依赖任何东西，应该用于通常不会通过 IoC 容器管理的依赖项。