抠丁客
Autofac 在容器构建时运行代码
Autofac 提供了组件在构建容器时被通知或自动激活的能力。
有三种自动激活机制可用：
- 可启动组件
- 自动激活组件
- 容器构建回调
在所有情况下，当容器被构建时，组件将被激活。
注意 避免过度使用启动逻辑：在容器构建时运行启动逻辑可能会感觉也很适合用于协调一般的应用程序启动逻辑。应用程序启动是依赖管理的另一个关注点。鉴于您可能遇到的顺序和其他挑战，建议您将应用程序启动逻辑与依赖管理逻辑分开。
可启动组件
可启动组件是指在容器首次构建时由容器激活，并具有特定方法调用来启动组件操作的组件。
关键在于实现 Autofac.IStartable 接口。当容器构建时，组件将被激活，IStartable.Start() 方法将被调用。
**这只会发生在每个组件的单个实例第一次构建容器时。**手动解析可启动组件不会导致其 Start() 方法被调用。不推荐将可启动组件注册为除 SingleInstance() 之外的任何内容。
需要像 Start() 方法那样每次激活时都调用的方法的组件应该使用 生命周期事件 ，如 OnActivated。
要创建一个可启动组件，请实现 Autofac.IStartable：
public class StartupMessageWriter : IStartable
{
public void Start()
{
Console.WriteLine("App is starting up!");
}
}
然后注册您的组件，并确保将其指定为 IStartable ，否则操作将不会执行：
var builder = new ContainerBuilder();
builder
.RegisterType<StartupMessageWriter>()
.As<IStartable>()
.SingleInstance();
当容器构建时，类型将被激活，并且 IStartable.Start() 方法将被调用。在这个示例中，将向控制台写入一条消息。
组件启动的顺序未定义，但自 Autofac 4.7.0 以来，如果一个实现了 IStartable 的组件依赖于另一个 IStartable 组件，则在依赖组件被激活之前，Start() 方法将保证已被调用：
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.RegisterType<Startable1>().AsSelf().As<IStartable>().SingleInstance();
builder.RegisterType<Startable2>().As<IStartable>().SingleInstance();
builder.Build();
}
class Startable1 : IStartable
{
public Startable1()
{
Console.WriteLine("Startable1 activated");
}
public void Start()
{
Console.WriteLine("Startable1 started");
}
}
class Startable2 : IStartable
{
public Startable2(Startable1 startable1)
{
Console.WriteLine("Startable2 activated");
}
public void Start()
{
Console.WriteLine("Startable2 started");
}
}
输出如下：
Startable1 activated
Startable1 started
Startable2 activated
Startable2 started
自动激活组件
自动激活组件是指在容器构建时仅需激活一次的组件。这是一种 “预热” 行为，不需要在组件上调用任何方法，也不需要实现任何接口——只需解析组件实例，而无需持有该实例的引用。
要注册一个自动激活组件，请使用 AutoActivate() 注册扩展。
var builder = new ContainerBuilder();
builder
.RegisterType<TypeRequiringWarmStart>()
.AsSelf()
.AutoActivate();
注意：如果您在注册
AutoActivate()组件时省略AsSelf()或As<T>()服务注册调用，则组件将仅注册为自动激活，并且在容器构建后不一定可以按自身进行解析。
构建回调
您可以注册任何任意动作在容器或生命周期范围构建时间发生。构建回调是一个 Action<IContainer> ，在返回容器之前，它将在容器构建之前执行。构建回调按照注册的顺序执行：
var builder = new ContainerBuilder();
builder
.RegisterBuildCallback(c => c.Resolve<DbContext>());
// 咨询：构建回调将在容器构建后运行，但在返回容器之前。
var container = builder.Build();
您可以使用构建回调作为另一种自动在容器构建时启动/预热对象的方式。通过它们与生命周期事件 OnActivated 和 SingleInstance 注册结合使用来实现这一点。
一个冗长且复杂的单元测试形式示例：
public class TestClass
{
// 创建依赖链，如
// ==> 2 ==+
// 4 =+ ==> 1
// ==> 3 ==+
// 4 需要 2 和 3
// 2 需要 1
// 3 需要 1
// 依赖项应按以下顺序启动
// 1, 2, 3, 4
// 或
// 1, 3, 2, 4
private class Dependency1
{
public Dependency1(ITestOutputHelper output)
{
output.WriteLine("Dependency1.ctor");
}
}
private class Dependency2
{
private ITestOutputHelper output;
public Dependency2(ITestOutputHelper output, Dependency1 dependency)
{
this.output = output;
output.WriteLine("Dependency2.ctor");
}
public void Initialize()
{
this.output.WriteLine("Dependency2.Initialize");
}
}
private class Dependency3
{
private ITestOutputHelper output;
public Dependency3(ITestOutputHelper output, Dependency1 dependency)
{
this.output = output;
output.WriteLine("Dependency3.ctor");
}
public void Initialize()
{
this.output.WriteLine("Dependency3.Initialize");
}
}
private class Dependency4
{
private ITestOutputHelper output;
public Dependency4(ITestOutputHelper output, Dependency2 dependency2, Dependency3 dependency3)
{
this.output = output;
output.WriteLine("Dependency4.ctor");
}
public void Initialize()
{
this.output.WriteLine("Dependency4.Initialize");
}
}
// Xunit将此传递给测试类的构造函数，以便捕获控制台输出。
private ITestOutputHelper _output;
public TestClass(ITestOutputHelper output)
{
this._output = output;
}
[Fact]
public void OnActivatedDependencyChain()
{
var builder = new ContainerBuilder();
builder.RegisterInstance(this._output).As<ITestOutputHelper>();
builder.RegisterType<Dependency1>().SingleInstance();
// OnActivated取代了对IStartable的需求。当实例被创建/激活时，将按照指定方式运行Initialize方法。使用SingleInstance意味着只发生一次。
builder.RegisterType<Dependency2>().SingleInstance().OnActivated(args => args.Instance.Initialize());
builder.RegisterType<Dependency3>().SingleInstance().OnActivated(args => args.Instance.Initialize());
builder.RegisterType<Dependency4>().SingleInstance().OnActivated(args => args.Instance.Initialize());
// 注意这些不是依赖顺序。
builder.RegisterBuildCallback(c => c.Resolve<Dependency4>());
builder.RegisterBuildCallback(c => c.Resolve<Dependency2>());
builder.RegisterBuildCallback(c => c.Resolve<Dependency1>());
builder.RegisterBuildCallback(c => c.Resolve<Dependency3>());
// 这将运行构建回调。
var container = builder.Build();
// 这些实际上什么也没做。因为它们是SingleInstance，所以OnActivated不会再被调用。
container.Resolve<Dependency1>();
container.Resolve<Dependency2>();
container.Resolve<Dependency3>();
container.Resolve<Dependency4>();
}
}
这个示例单元测试将生成以下输出：
Dependency1.ctor
Dependency2.ctor
Dependency3.ctor
Dependency4.ctor
Dependency2.Initialize
Dependency3.Initialize
Dependency4.Initialize
从输出中可以看出，回调和 OnActivated 方法按依赖顺序执行。如果您必须使初始化和启动都在依赖顺序（不仅仅是激活/解析）下发生，这是解决办法。
请注意，如果不使用 SingleInstance ，则 OnActivated 将为每个依赖项的新实例调用一次。由于预热对象通常是单例，并且创建起来很昂贵，这通常正是您想要的。
生命周期范围
使用 SingleInstance 或 InstancePerDependency 以外的方式注册 IStartable 或 AutoActivate 可能不如您期望的工作。
例如，如果使用 InstancePerLifetimeScope 注册，这并不会导致在您创建的每个生命周期范围内都启动一个新的可启动组件。相反，可启动组件将在容器构建时运行。
此外，您不能在命名生命周期范围中使用 IStartable 或 AutoActivate。在命名范围创建时注册将不会启动组件；相反，它会在尝试启动组件时引发异常，因为命名范围不存在。
static void Main(string[] args)
{
var builder = new ContainerBuilder();
// 这将无法正常工作。当容器尝试启动组件时，会得到一个依赖解析异常，因为命名生命周期范围不存在。
builder.RegisterType<Startable1>()
.As<IStartable>()
.InstancePerMatchingLifetimeScope("unitOfWork");
builder.Build();
}
如果你需要在特定生命周期范围中启动某些内容，你需要在创建该范围时（即，在 BeginLifetimeScope 调用中）进行注册。
static void Main(string[] args)
{
var builder = new ContainerBuilder();
var container = builder.Build();
using (var uow = container.BeginLifetimeScope("unitOfWork", b => b.RegisterType<Startable1>().As<IStartable>()))
{
// 启动器已经运行了。
}
}
构建回调将在容器级别和范围级别上工作。它们会在指定的级别上运行。
var builder = new ContainerBuilder();
builder.RegisterBuildCallback(
c => Console.WriteLine("这发生在容器构建时。"));
using var container = builder.Build();
using var scope = container.BeginLifetimeScope(
b => b.RegisterBuildCallback(
c => Console.WriteLine("这发生在范围构建时。")));
小提示
尽可能避免启动逻辑：在容器构建时运行启动逻辑非常方便，但依赖注入容器主要用于对象的连接，而不是应用程序的启动。尽可能地将这些关注点分开是个好主意。
顺序：通常，启动逻辑的执行顺序是
IStartable.Start()、AutoActivate和构建回调。然而，这并不是强制性的。例如，如IStartable文档中所述，事情会按照依赖顺序而不是注册顺序发生。此外，Autofac 保留更改此顺序的权利（例如，重构对IStartable.Start()和AutoActivate的调用到构建回调）。如果你需要控制初始化逻辑的确切执行顺序，最好自己编写初始化逻辑，以便可以控制顺序。
避免在
IStartable.Start或AutoActivate中创建生命周期范围：如果你的启动逻辑包括从其中解析组件的生命周期范围的创建，那么这个范围还没有执行所有的启动器。通过创建范围，你迫使了一个竞争条件。这种逻辑更适合在容器构建后执行自定义逻辑，而不是作为IStartable的一部分。
考虑使用
OnActivated和SingleInstance进行懒加载：与其使用构建回调或启动逻辑，不如考虑使用生命周期事件OnActivated以及SingleInstance注册，这样初始化可以在对象上发生，但不受容器构建顺序的约束。