ASP.net Web API：为什么要根据请求创建控制器？答案

【问题标题】：ASP.net Web API: Why are controllers created per request?ASP.net Web API：为什么要根据请求创建控制器？
【发布时间】：2014-08-07 06:31:43
【问题描述】：

Mike Wasson 在 www.asp.net 上的文章“Dependency Injection for Web API Controllers”说：

依赖范围和控制器生命周期

根据请求创建控制器...

我是否正确理解 ASP.NET Web API 为每个传入请求创建一个新的控制器实例（并满足其依赖关系）？

当理论上单个实例可以用于所有请求时，这种方法是否会创建和销毁控制器的许多实例而不浪费？

【问题讨论】：

理论上，当然；但是.NET 中的对象创建（和销毁）并不昂贵。 ASP.NET MVC（和 WebAPI）中的控制器是相对简单的对象，当然，每个请求的旧 Web 窗体 Page 的实例化可能要昂贵得多。
保持有状态控制器也存在实际问题：您需要额外的工作来执行单独的每个请求清理（例如数据库连接）和每个实例清理（例如控制器状态）。重入性和并发性也存在问题（ASP.NET 对每个请求使用不同的线程）。为每个请求使用一个控制器实例当然更简单、更可靠。
由于 HTTP 是一种无状态协议，它是一种以无状态方式处理请求的自然方式 ...
在某些依赖注入框架（例如 Castle）中，您可以使用池化生命周期，其中 DI 框架会自动初始化您的依赖项的 n 个资源，并将它们保存在一个池中，以便在有人请求该服务时重用（可能以循环方式）。请记住陷阱，例如该服务的销毁/最终确定通常会例如结束可以正确完成操作的事务，在 Castle 中，您可以通过实现每次回收调用的接口方法来解决此问题。

【解决方案1】：

控制器包含有关传入请求的信息（状态）。

如果你只有一个控制器来处理许多请求，那么他们都会感到困惑，用户可能会得到一些奇怪的结果。

【讨论】：

感谢@rowan-freeman。你能详细说明吗？控制器包含关于请求的什么状态？
@urig 好吧，首先是Request 属性。
“所有的请求状态最初都来自 HttpContext”：这是错误的。 Web Api 使用自己的操作/控制器/请求上下文，由框架在每个传入请求时填充，并且不依赖于System.Web dll。（即您可以自托管 Web Api 项目）。
不相信，如果我们不在控制器中维护任何实例变量/状态，那么“用户可能会得到一些奇怪的结果”。 ?
您可能会也可能不会直接这样做，但框架是。控制器具有ControllerContext 属性、HttpContext 属性、Request 属性、Response 属性、Session 属性和User 属性。这些属性包含有关当前 HTTP 请求、用户、会话以及将返回给用户的内容的状态。如果您尝试使用单个 Controller 对象，用户可能会看到完全不同用户的路由和用户，或者可能只是服务器错误。

【解决方案2】：

如果不是每个请求都重新创建它，您实际上将拥有一个单例或静态类，这意味着您需要处理在异常和各种其他情况下重置类状态。结果几乎肯定意味着错误。

每次创建新上下文的开销只是为了更好的代码可维护性而付出的很小的代价。

【讨论】：