Question

我的应用程序与VS 2013的Web API默认模板完全相同。基本上，Web API 2用于API，MVC 5用于文档。

我正在使用 Autofac ，到目前为止它运行良好。以下是我所拥有的精简版 -

var builder = new ContainerBuilder();

var assemblies = Assembly.GetExecutingAssembly();
builder.RegisterControllers(assemblies);
builder.RegisterApiControllers(assemblies);

builder.RegisterType<MyService>().As<IMyService>()
   .InstancePerHttpRequest();

var apiResolver = new AutofacWebApiDependencyResolver(container);
GlobalConfiguration.Configuration.DependencyResolver = apiResolver;

var mvcResolver = new AutofacDependencyResolver(container);
DependencyResolver.SetResolver(mvcResolver);

到目前为止， InstancePerHttpRequest 适用于MVC和Web API。

问题

我想知道使用 InstancePerHttpRequest 而不是 InstancePerApiRequest 的缺点，所以如果我将来遇到问题，我不会感到惊讶。

我发现了类似的question，但它没有回答我的问题。

注意： 我在SO中找到了一些答案，说我们不应该在同一个项目中混合使用MVC和Web API。对我来说，我只需要很少的MVC网页来获取文档，所以我不想创建新的MVC项目。

提前致谢！

Answer 1

现在，InstancePerApiRequest和InstancePerHttpRequest方法完全相同 - 使用公共生命周期范围“name”注册InstancePerLifetimeScope。它实际上是InstancePerMatchingLifetimeScope("AutofacWebRequest")。

请求范围在Web表单，WebAPI和MVC集成中命名相同，因此它们都是可互换的。这是故意的。但是，由于挑战在于你可以混合搭配所有这些，或者只使用一个，我们必须为每种技术提供“相同的东西”。在论坛上有一个关于创建某种中央/基础“网络集成”库的讨论，该库在所有ASP.NET内容中都很常见，以消除混淆，但它将是一个突破性的变化，所以它不会发生一段时间

目前，您可以安全地使用这两个扩展名。

请注意，其他扩展名（例如InstancePerApiControllerType）执行不同的操作，因此只有“请求生命周期范围注册扩展”才可以互换。

在同一个项目中的MVC和Web API中使用InstancePerHttpRequest而不是InstancePerApiRequest有什么缺点？

问题

1 个答案: