如何通过类传播自动作用域/容器?

Question

将autofacc容器传播到不同的类并从不同的类访问它的正确方法是什么?

我理解文档的方式是，我将作用域作为构造函数参数添加到每个类中，如果调用类也通过autofacc解析，则将注入作用域(不确定在此上下文中是否注入是正确的术语)。

的例子:Program.cs

using Autofac;
namespace HelloWorld
{
public class Program
{
private static IContainer Container { get; set; }
static void Main(string[] args)
{
Console.WriteLine("Hello, World!");
var builder = new ContainerBuilder();
builder.RegisterType<Class1>();
builder.RegisterType<Class2>();
Container = builder.Build();
var obj1 = Container.Resolve<Class1>();
obj1.Write();
}
}
}

Class1.cs

using Autofac;
namespace HelloWorld
{
internal class Class1
{
public Class1(ILifetimeScope scope)
{
_scope = scope.BeginLifetimeScope();
}
public void Write()
{
var class2 = _scope.Resolve<Class2>();
class2.Write();
}
private readonly ILifetimeScope _scope;
}
}

Class2.cs

namespace HelloWorld
{
internal class Class2
{
public void Write()
{
Console.WriteLine("Hello, I'm class 2.");
}
}
}

输出:
Hello, World!
大家好，我是二班。

这个例子可以工作，但是，我觉得处理作用域和手动解析的开销很大。那么，这是使用自动识别的预期方式吗?

Answer 1

这里有两个问题。第一个问题是如何通过类传播作用域，这有点像字面问题;但第二个更含蓄，关于你实际想要做什么。

第一个问题-如何通过类传播作用域?你的想法是对的。如果你想访问被解析对象的生命周期范围，你可以添加一个ILifetimeScope属性，如果你需要，你可以使用它来做服务定位。

第二个问题-这是使用Autofac的预期方式吗?:这个比Autofac还大。你需要做的是看看"依赖注入"以及"控制反转";是这样的。这些都不是autofactspecific模式。

一般情况下你不应该做service location换句话说，您几乎不应该需要注入生命周期作用域并尝试手动解决某些问题。在有趣的边缘情况下也有例外，但这就是为什么我说一般就是这种情况。

一般情况下只需添加所需的构造函数参数即可。这就是控制反转容器(在本例中是Autofac)的全部意义所在——它会查看您的构造函数，并为您完成所有的Resolve和new调用。

Autofac文档中有一个很好的入门指南，展示了如何构建应用程序的基本步骤。我强烈建议你阅读这些文档，并花一些时间研究依赖注入。当你搜索的时候，考虑不要输入"autofacfac"特别是在搜索词列表中，因为该模式比Autofac，甚至。net要大得多——它是一种通用的编程模式。

为了使您的示例更加具体，您将更改Class1，使其不包含服务位置。Autofac处理连接。

namespace HelloWorld
{
internal class Class1
{
public Class1(Class2 class2)
{
// Autofac sees this and automatically resolves
// it from the lifetime scope.
_class2 = class2;
}
public void Write()
{
this._class2.Write();
}
private readonly Class2 _class2;
}
}