依赖注入 – 为需要异步初始化的类型避免所有DI反模式

我有一个类型连接需要异步初始化。这种类型的实例被其他几种类型(例如，存储)使用，每种类型也需要异步初始化(静态，不是每个实例，并且这些初始化也依赖于Connections)。最后，我的逻辑类型(例如，逻辑)消耗这些存储实例。目前使用Simple Injector。

我尝试了几种不同的解决方案，但总有一种反模式存在。

显式初始化(??时间耦合)

我目前使用的解决方案有Temporal Coupling反模式：

public sealed class Connections
{
  Task InitializeAsync();
}

public sealed class Storage : IStorage
{
  public Storage(Connections connections);
  public static Task InitializeAsync(Connections connections);
}

public sealed class Logic
{
  public Logic(IStorage storage);
}

public static class GlobalConfig
{
  public static async Task EnsureInitialized()
  {
    var connections = Container.GetInstance<Connections>();
    await connections.InitializeAsync();
    await Storage.InitializeAsync(connections);
  }
}

我将Temporal Coupling封装成一种方法，所以它并没有那么糟糕。但是，它仍然是一个反模式，而不是像我想的那样可维护。

抽象工厂(同步异步)

常见的解决方案是抽象工厂模式。但是，在这种情况下，我们正在处理异步初始化。因此，我可以通过强制初始化同步运行来使用抽象工厂，但这会采用sync-over-async反模式。我真的不喜欢异步同步方法，因为我有几个存储空间，在我当前的代码中，它们都是同时初始化的;由于这是一个云应用程序，将其更改为串行同步会增加启动时间，并且由于资源消耗，并行同步也不理想。

异步抽象工厂(不正确的抽象工厂用法)

我也可以使用Abstract Factory和异步工厂方法。但是，这种方法存在一个主要问题。正如马克·西曼(Mark Seeman)评论here所说的那样，“如果你正确注册，任何值得盐的DI容器都能为你自动连接[工厂]实例。”不幸的是，对于异步工厂来说这是完全不正确的：AFAIK没有支持这种情况的DI容器。

因此，抽象异步工厂解决方案将要求我使用显式工厂，至少Func< Task< T>>和this ends up being everywhere(“我们个人认为允许默认注册Func委托是一种设计气味……如果您的系统中有许多依赖于Func的构造函数，请仔细查看您的依赖策略。“)：

public sealed class Connections
{
  private Connections();
  public static Task<Connections> CreateAsync();
}

public sealed class Storage : IStorage
{
  // Use static Lazy internally for my own static initialization
  public static Task<Storage> CreateAsync(Func<Task<Connections>> connections);
}

public sealed class Logic
{
  public Logic(Func<Task<IStorage>> storage);
}

这导致了它自己的几个问题：

>我的所有工厂注册都必须明确地从容器中提取依赖项并将它们传递给CreateAsync。因此，DI容器不再执行依赖注入。
>这些工厂调用的结果具有不再由DI容器管理的生命周期。现在每个工厂都负责终身管理，而不是DI容器。 (使用同步抽象工厂，如果工厂已正确注册，则不会出现问题)。
>实际使用这些依赖项的任何方法都需要是异步的 – 因为即使是逻辑方法也必须等待存储/连接初始化完成。这对我来说对这个应用程序来说不是什么大问题，因为我的存储方法无论如何都是异步的，但在一般情况下它可能是个问题。

自初始化(时间耦合)

另一种不太常见的解决方案是让一个类型的每个成员等待它自己的初始化：

public sealed class Connections
{
  private Task InitializeAsync(); // Use Lazy internally

  // Used to be a property BobConnection
  public X GetBobConnectionAsync()
  {
    await InitializeAsync();
    return BobConnection;
  }
}

public sealed class Storage : IStorage
{
  public Storage(Connections connections);
  private static Task InitializeAsync(Connections connections); // Use Lazy internally
  public async Task<Y> IStorage.GetAsync()
  {
    await InitializeAsync(_connections);
    var connection = await _connections.GetBobConnectionAsync();
    return await connection.GetYAsync();
  }
}

public sealed class Logic
{
  public Logic(IStorage storage);
  public async Task<Y> GetAsync()
  {
    return await _storage.GetAsync();
  }
}

这里的问题是我们回到了时间耦合，这次遍布整个系统。此外，此方法要求所有公共成员都是异步方法。

那么，真的有两个DI设计视角在这里不一致：

>消费者希望能够注入可以使用的实例。
> DI容器为simple constructors努力推进。

问题是 – 特别是对于异步初始化 – 如果DI容器对“简单构造函数”方法采取强硬路线，那么它们只是强迫用户在其他地方进行自己的初始化，这带来了自己的反模式。例如，why Simple Injector won’t consider asynchronous functions：“不，这种功能对于Simple Injector或任何其他DI容器没有意义，因为它涉及依赖注入时违反了一些重要的基本规则。”然而，严格按照“基本规则”进行游戏显然迫使其他反模式看起来更糟糕。

问题：是否存在避免所有反模式的异步初始化的解决方案？

更新：AzureConnections的完整签名(以上称为Connections)：

public sealed class AzureConnections
{
  public AzureConnections();

  public CloudStorageAccount CloudStorageAccount { get; }
  public CloudBlobClient CloudBlobClient { get; }
  public CloudTableClient CloudTableClient { get; }

  public async Task InitializeAsync();
}