工厂对直接依赖注入的好处答案

【问题标题】：Benefit of Factory over Direct Dependency Injection工厂对直接依赖注入的好处
【发布时间】：2015-12-22 19:20:20
【问题描述】：

我遇到了这段代码：

public class SomeServiceFactory : ISomeServiceFactory
{
    private IUnityContainer container;

    public SomeServiceFactory(IUnityContainer unityContainer)
    {
        this.container = unityContainer;
    }

    public virtual ISomeService GetSomeService()
    {
        return this.container.Resolve<ISomeService>();
    }
}

我试图了解这种模式如何更有用，然后简单地让这个工厂的消费者直接注入ISomeService？因此，成为服务本身的消费者，而不是工厂。这个额外的间接层实现了什么，如此处实现的？

我知道，如果 ISomeService 的创建需要更复杂的逻辑，而 container.Resolve 无法实现，那么肯定需要一个工厂。

【问题讨论】：

标签： dependency-injection unity-container factory

【解决方案1】：

好问题。如果没有上下文信息，就很难捍卫这样一个退化的抽象工厂。

有时，原因可能是编写该工厂消费者的程序员知道 ISomeService 实现必须为每次使用重新创建；也许那个特定的实现不是线程安全的。

此外，ISomeService 可能派生自 IDisposable，也许客户端会这样做：

using (var svc = this.factory.GetSomeService())
{
    // use svc here...
}

这会导致svc 在使用后被妥善处理。

以上所有都是有漏洞的抽象，但仍然很常见。

处理此类生命周期和资源管理问题的更好方法是通过Decoraptor 或Register Resolve Release pattern。

然而，这仍然可能需要你有一个像 SomeServiceFactory 这样的类，然后是 it'd be an infrastructure component，例如支持 Decoraptor。

但是请注意，这个特定的抽象工厂是退化的，因为它不接受方法参数。另一方面，具有一个或多个方法参数的抽象工厂是 common solution to the problem of creating a polymorphic service based on a run-time value。

【讨论】：