C# Autofac+；工厂方法模式 背景

根据“四人帮”，工厂方法模式用于

定义用于创建对象的接口，但由子类决定 要实例化的类。工厂方法允许类延迟 它用于子类的实例化

相反，我使用它来异步构造具有耗时构造函数的类。让我们假设这个类

public class MyClass
{
    private readonly IA _a;

    private MyClass(IA a)
    {
        _a = a;
    }

    public static MyClass Create(IA a)
    {
        var instance = new MyClass(a);
        instance.InitializeAsync().Wait();
        return instance;
    }

    public static async Task<MyClass> CreateAsync(IA a)
    {
        var instance = new MyClass(a);
        await instance.InitializeAsync();
        return instance;
    }

    private Task InitializeAsync()
    {
        return Task.Run(() =>
        {
            Task.Delay(5000).Wait();
        });
    }
}

我已经注册了同步创建和异步创建。让我们举例说明异步创建，让Autofac为我们解析类：

var myInstance = await IoCProxy.RootLifetimeScope.Resolve<Task<MyClass>>();

var myInstance=wait IoCProxy.RootLifetimeScope.Resolve（）；

到目前为止，我对这个解决方案非常满意。我可以隐藏在autofac注册内部创建的调用，因此对于解析MyClass的人来说，语法将与正常语法一样，但还有一个额外的好处，就是能够

等待

问题

---

我唯一的问题是，我被迫手动解析

Create（）

方法中定义的每个依赖项。对于这个例子，我只有一个依赖项

IA

，但是对于我的许多类，我注入了10+个依赖项。对于构造函数注入，Autofac使用反射遍历所有构造函数参数，但在使用

Register（）

时，我避开了此功能。是否有其他方法要求Autofac为我自动解析参数？

请参阅和。我认为你看错了这个问题。您的构造函数所做的不应该超过分配依赖项。如果它们花费的时间太长，则会出现代码气味，表明您违反了此规则和/或某个/某些依赖项的容器生存期太短。为了回避实际问题，您增加了很多复杂性。这是一个非常有价值的观点，Mark Seemann给出了非常好的理由来解释为什么要保持构造函数简单（快速创建对象图和实线中的S）。然而，我仍然没有一个好的位置来进行复杂的初始化。Mark Seemann甚至放弃使用单独的初始化函数，因为它与其他属性存在时间依赖关系。这正是我想将此代码移动到构造函数的原因。那么我应该把这些代码放在哪里呢？马克·西曼实际上已经回答了很多关于stackoverflow上IoC+初始化的问题。他们都有相同的答案：抽象工厂。因此，我会仔细阅读，然后带着答案回来，以防没人能比我更了解它。

var myInstance = await IoCProxy.RootLifetimeScope.Resolve<Task<MyClass>>();