我对使用 Autofac 还是很陌生，我在文档和示例中错过的一件事是如何轻松地从 Web 应用程序的不同位置访问已配置的容器。
我知道我可以使用 Autofac 控制器工厂来自动解析控制器的构造函数注入依赖项，但是您可能需要解决尚未注入的其他内容呢。
是否存在我不知道的明显模式？
谢谢！
【问题讨论】：
DependencyResolver.Current 是您所需要的，无论您使用的是 Autofac 还是其他东西。
标签： asp.net dependency-injection inversion-of-control autofac
Autofac 的“方式”是有一个IContext 构造函数参数。 Autofac 将注入一个可用于解析类型的对象。
上下文通常是幕后的容器，IContainer 实现了IContext 接口，尽管IContext 仅限于做解析。
我知道容器不应该被“过度使用”，但作为 OP，我有需要解析提前不知道的类型的类（因此不能用作构造函数参数）。我发现在这些情况下很有用，将容器视为可用于解析其他服务的另一个服务，并像任何其他服务一样注入它。
如果您觉得使用 IContext 会将您绑定到 Autofac，并且您需要使用自己的接口对其进行抽象，那么只需在您的容器中注册一个 IContext 包装类即可。
更新：在 Autofac 2 中，IContext 被称为 IComponentContext。
【讨论】：
首先尽量不要过度使用 IoC 容器。它非常适合“连接”控制器、视图和服务，但需要在运行时创建的对象应该由工厂对象而不是容器创建。否则，您将通过您的代码获得 Container.Resolve 调用，并将其绑定到您的容器。这些额外的依赖破坏了使用 IoC 的目的。在大多数情况下，我只需在应用程序的顶层解决一两个依赖项即可。然后 IoC 容器将递归地解决大多数依赖项。
当我在程序的其他地方需要容器时，这是我经常使用的一个技巧。
public class Container : IContainer
{
readonly IWindsorContainer container;
public Container()
{
// Initialize container
container = new WindsorContainer(new XmlInterpreter(new FileResource("castle.xml")));
// Register yourself
container.Kernel.AddComponentInstance<IContainer>(this);
}
public T Resolve<T>()
{
return container.Resolve<T>();
}
}
我将容器包装在这样的 Container 类中。它将自己添加到构造函数中的包装容器中。现在，需要容器的类可以注入 IContainer。 （该示例适用于温莎城堡，但它可能适用于 AutoFac）
【讨论】：
让 IOC 容器在全球范围内可用并不是最佳做法。甚至passing container is not encouraged。
如果不能使用依赖注入（你需要在创建组件后创建\request对象）那么你可以：
【讨论】：
Peter Lillevold 上面的回答是正确的 - 您可以通过依赖 IContext 接口从任何组件访问容器。
如果您真的确实需要实际的容器引用，请参阅 Autofac.Integration.Web.IContainerProviderAccessor。
【讨论】：
执行此操作的常用方法是将容器存储在全局应用程序类的静态变量中。
【讨论】：