Autofac多次注册组件

在上一个关于如何可视化依赖关系图的问题中 https://stackoverflow.com/a/59247007/1955317我为现在用来可视化我的依赖关系图的代码奠定了基础，因为它是由 Autofac 解析的。

运行代码，我得到一棵树，生成如下代码。

Usd.EA.Bogfoering.WebApi.Controllers.BogfoerController (3851,7 ms. / 0,0 ms.) Depth: 0
   Usd.EA.Bogfoering.WebApi.Controllers.BogfoerController (3851,7 ms. / 0,4 ms.) Depth: 1
      Usd.Utilities.WebApi.Controllers.UnikOwinContext (0,1 ms. / 0,0 ms.) Depth: 2
         Usd.Utilities.WebApi.Controllers.UnikOwinContext (0,1 ms. / 0,0 ms.) Depth: 3

一开始我认为代码有问题，并且由于某种原因导致组件多次得到解决。正如 Steven 指出的，当组件注册为InstancePerDependency。但由于我的几个组件被注册为InstancePerLifetime or SingleInstance依赖关系，这些依赖关系不应在图中解析两次。

史蒂文确实提到 https://stackoverflow.com/questions/59246792/visualizing-dependency-tree-depth-in-autofac/59247007#comment104809677_59247007 that "第一个决心InstancePerDependency依赖关系似乎比下一个解析有更多的依赖关系，因为该图仅显示解析。也许这就是正在发生的事情。“但正如我所看到的InstancePerLifetime组件被多次注册，在整个图表中多次出现，我感觉这里还发生了其他事情。

这里可能发生了什么？

如何注册依赖项

以下代码是我们用来注册程序集的代码：

public static void RegisterAssemblies(this ContainerBuilder containerBuilder, IList<Assembly> assemblies, params Type[] typesToExclude)
{
  if (containerBuilder != null && assemblies.Any())
  {
    var allTypes = assemblies.SelectMany(assembly => assembly.GetTypes()).Where(t => !typesToExclude.Any(t2 => t2.IsAssignableFrom(t))).ToList();
    RegisterAllClassesWithoutAttribute(containerBuilder, allTypes);

    RegisterClassesThatAreSingleton(containerBuilder, allTypes);

    RegisterClassesThatAreInstancePerLifetimeScope(containerBuilder, allTypes);

    RegisterGenericInterfaces(containerBuilder, allTypes);

    RegisterRealOrTestImplementations(containerBuilder, allTypes);

    RegisterAutofacModules(containerBuilder, allTypes);

    containerBuilder.Register(c => UnikCallContextProvider.CurrentContext).As<IUnikCallContext>();
  }
}

private static void RegisterAutofacModules(ContainerBuilder containerBuilder, List<Type> allTypes)
{
  var modules = allTypes.Where(type => typeof(IModule).IsAssignableFrom(type) && type.GetCustomAttribute<DoNotRegisterInIocAttribute>() == null);
  foreach (var module in modules)
  {
    containerBuilder.RegisterModule((IModule) Activator.CreateInstance(module));
  }
}

private static void RegisterRealOrTestImplementations(ContainerBuilder containerBuilder, List<Type> allTypes)
{
  if (StaticConfigurationHelper.UseRealImplementationsInsteadOfTestImplementations)
  {
    var realTypes = allTypes.Where(type => type.GetCustomAttribute<RealImplementationAsInstancePerLifetimeScopeAttribute>() != null).ToArray();
    containerBuilder.RegisterTypes(realTypes).AsImplementedInterfaces()
      .InstancePerLifetimeScope();
  }
  else
  {
    var testTypes = allTypes.Where(type => type.GetCustomAttribute<TestImplementationAsInstancePerLifetimeScopeAttribute>() != null).ToArray();
    containerBuilder.RegisterTypes(testTypes).AsImplementedInterfaces()
      .InstancePerLifetimeScope();
  }
}

private static void RegisterGenericInterfaces(ContainerBuilder containerBuilder, List<Type> allTypes)
{
  var typesAsGenericInterface = allTypes.Where(type => type.GetCustomAttribute<RegisterAsGenericInterfaceAttribute>() != null).ToArray();
  foreach (var type in typesAsGenericInterface)
  {
    var attribute = type.GetCustomAttribute<RegisterAsGenericInterfaceAttribute>();
    containerBuilder.RegisterGeneric(type).As(attribute.Type);
  }
}

private static void RegisterClassesThatAreInstancePerLifetimeScope(ContainerBuilder containerBuilder, List<Type> allTypes)
{
  var typesAsInstancePerDependency = allTypes.Where(type => type.GetCustomAttribute<InstancePerLifetimeScopeAttribute>() != null).ToArray();
  containerBuilder.RegisterTypes(typesAsInstancePerDependency).InstancePerLifetimeScope().AsImplementedInterfaces();
}

private static void RegisterClassesThatAreSingleton(ContainerBuilder containerBuilder, List<Type> allTypes)
{
  var typesAsSingleton = allTypes.Where(type => type.GetCustomAttribute<SingletonAttribute>() != null).ToArray();
  containerBuilder.RegisterTypes(typesAsSingleton).SingleInstance().AsImplementedInterfaces();
}

private static void RegisterAllClassesWithoutAttribute(ContainerBuilder containerBuilder, List<Type> allTypes)
{
  var types = allTypes.Where(type => !typeof(IModule).IsAssignableFrom(type) &&
                                     type.GetCustomAttribute<DoNotRegisterInIocAttribute>() == null &&
                                     type.GetCustomAttribute<SingletonAttribute>() == null &&
                                     type.GetCustomAttribute<RealImplementationAsInstancePerLifetimeScopeAttribute>() == null &&
                                     type.GetCustomAttribute<TestImplementationAsInstancePerLifetimeScopeAttribute>() == null &&
                                     type.GetCustomAttribute<InstancePerLifetimeScopeAttribute>() == null &&
                                     type.GetCustomAttribute<RegisterAsGenericInterfaceAttribute>() == null).ToArray();
  containerBuilder.RegisterTypes(types).AsSelf().AsImplementedInterfaces();
}

交付到的组件RegisterAssemblies方法可以这样获取：

private List<Assembly> GetAssemblies()
{
  var assemblies = AssemblyResolveHelper.LoadAssemblies(AppDomain.CurrentDomain.BaseDirectory,
    new Regex(@"Usd.EA.*\.dll"),
    SearchOption.TopDirectoryOnly);
  assemblies.AddRange(AssemblyResolveHelper.LoadAssemblies(AppDomain.CurrentDomain.BaseDirectory,
    new Regex(@"Usd.Utilities.*\.dll"),
    SearchOption.TopDirectoryOnly));

  assemblies.Add(GetType().Assembly);
  return assemblies.Distinct().ToList();
}

属性

中使用的属性RegisterAllClassesWithoutAttribute是我们手动分配给各个类的自定义属性

using System;

[AttributeUsage(AttributeTargets.Class)]
public class DoNotRegisterInIocAttribute : Attribute
{
}

像这样使用

[ExcludeFromCodeCoverage]
[DoNotRegisterInIoc]
public sealed class TestClass : ITestClass

当我不覆盖 Autofacs 时MaxResolveDepth我收到以下错误

失败 尝试创建类型的控制器时发生错误 'BogfoerController'。确保控制器具有无参数 公共构造函数。激活 λ:Usd.EA 时抛出异常 .Bogfoering.WebApi.Controllers.BogfoerController -> Usd.EA.Bogfoering.WebApi.Controllers.BogfoerController -> ...... 工厂范围的组件之间可能存在循环依赖。链 包括'Activator = DomainWrapper（DelegateActivator），Services = SomeService，生命周期= Autofac.Core.Lifetime.CurrentScopeLifetime， 共享=无，所有权=外部拥有'

简短回答：这是由解析子级服务时 Autofac 行为引起的ILifetimeScope通过调用创建BeginLifetimeScope(Action<ContainerBuilder> configurationAction).

长答案：我设置了一个简单的测试来证明上述说法。我已经生成了 51 个引用自身的测试类。

public class Test0
{
    public Test0() { }
}

public class Test1
{
    public Test1(Test0 test) { }
}

(...)

public class Test50
{
    public Test50(Test49 test) { }
}

将它们注册到新创建的容器中，并尝试直接从容器解析“Test50”类。正如你已经发现的那样。 Autofac 库中存在 50 个依赖项深度的硬编码限制，您可以在GitHub https://github.com/bstewart00/Autofac/blob/develop/src/Autofac/Core/Resolving/CircularDependencyDetector.cs页。达到此限制后DependencyResolutionException被抛出并声明“工厂范围的组件之间可能存在循环依赖。“这正是我第一次测试中发生的情况。

现在您可能会问，为什么会看到相同依赖项的多个注册。那么有趣的部分来了。当您尝试解析实例时，您可能会使用BeginLifetimeScope函数创建新的 ILifetimeScope。这仍然没问题，除非您要使用其中一个重载向子作用域添加一些新的注册。请参阅下面的示例：

using (var scope = container.BeginLifetimeScope(b => { }))
{
    var test = scope.Resolve<Test49>();
}

我只解决了 50 个依赖项（以前有效），但现在它产生了一个异常：

正如您所看到的，这与您之前描述的行为完全相同。每个依赖项现在显示 2 次。在该图像上，您还可以看到依赖图仅达到Test25班级。这有效地将之前的最大深度减少了一半（总共 25 个依赖项！）。我们可以通过成功解决来测试这一点Test24类，但在尝试解析时抛出异常Test25。这更有趣，你认为，如果我们添加另一个作用域会发生什么？

using (var scope1 = container.BeginLifetimeScope(b => { }))
{
    using (var scope2 = scope1.BeginLifetimeScope(b => { }))
    {
        var test2 = scope2.Resolve<Test49>();
    }
}

您可能已经猜到了，现在您只能解析深度 50 / 3 = ~16 的依赖关系。

结论：创建嵌套作用域将依赖关系图的实际可用最大深度限制为 N 倍，其中 N 是作用域的深度。老实说，在不扩展容器构建器的情况下创建的范围不会影响这个数字。在我看来，这是一个巨大的荒谬，拥有硬编码的幻数，它在文档中没有任何地方，无法轻松配置，甚至不代表实际的最大深度，并且当溢出时，它会抛出误导性的异常，表明您图中某处存在循环依赖关系。

解决方案：作为此问题的解决方案，您无法使用此函数的此重载。由于架构限制，甚至可能使用 Autofac 作为 DI 容器的第 3 方框架，这可能是不可能的。

您已经提到的另一个解决方案是使用脏反射覆盖 MaxResolveDepth。

string circularDependencyDetectorTypeName = typeof(IContainer).AssemblyQualifiedName.Replace(typeof(IContainer).FullName, "Autofac.Core.Resolving.CircularDependencyDetector");
Type circularDependencyDetectorType = Type.GetType(circularDependencyDetectorTypeName);
FieldInfo maxResolveDepthField = circularDependencyDetectorType.GetField("MaxResolveDepth", BindingFlags.Static | BindingFlags.NonPublic);

maxResolveDepthField.SetValue(null, 500);

在 Autofac 的 GitHub 上，您还可以了解到他们已经计划改变CircularDependencyDetector，因此它可以处理无限深度的依赖关系，但这些计划是在 2018 年提到的，他们甚至无法在这个日期之前更改该异常消息。