Question

我遇到了这段代码：

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无法实现，那么肯定需要工厂。

Answer 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。

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

1 个答案: