为什么 System.Web.HttpContext.Current.User 在控制器构造函数期间解析，但 User.Identity 没有答案

【问题标题】：Why does System.Web.HttpContext.Current.User resolve during a controller constructor, but User.Identity does not为什么 System.Web.HttpContext.Current.User 在控制器构造函数期间解析，但 User.Identity 没有
【发布时间】：2015-08-26 03:11:21
【问题描述】：

Rowan Freeman 对this question 的回答描述了为什么User.Identity 在控制器的构造函数中为空。对同一问题的评论指出，System.Web.HttpContext.Current.User 确实会在相同的上下文中产生预期值。

为什么System.Web.HttpContext.Current.User 在控制器的构造函数中有效，而User.Identity 无效？

在控制器的构造过程中使用System.Web.HttpContext.Current 是否会导致错误？

编辑澄清：

从链接的文章中，关于User.Identity：“控制器实例化将在授权发生之前发生。即使您的 MVC 应用程序多次调用 RenderAction() 并且您最终创建了五个不同的控制器，这五个控制器将是在任何 OnAuthorization 发生之前创建。"

上述段落是否不适用于System.Web.HttpContext.Current？我希望能更好地理解使它们表现出不同的两者之间的细微差别，希望了解System.Web.HttpContext.Current 是否可以在单个操作之外但在控制器内部使用。

【问题讨论】：

将逻辑放入控制器的构造函数通常是个坏主意。每个请求都会执行构造函数。最佳实践是除了分配依赖项外，不要在构造函数中做任何事情，然后在这些依赖服务中完成繁重的工作。另一种选择是使用authorization 或action filters。在控制器的构造函数中执行代码的方法有很多。
感谢您对此的看法。我正在考虑使用控制器构造函数来创建一个知道当前登录用户的 AspNetUserId 的数据服务类实例。这将允许控制器中的各个操作不需要将 AspNetUserId 传递到每个请求中。但我对 MVC 的理解不够深入，无法确定我没有引入脆弱性。

标签： c# asp.net-mvc asp.net-mvc-5 wif

【解决方案1】：

在控制器的构造过程中使用 System.Web.HttpContext.Current 会导致错误吗？

它会引入一个不受欢迎的依赖关系，例如，它会阻止您正确地对控制器进行单元测试。

您可以考虑覆盖Controller.Initialize 来添加您自己的初始化

【讨论】：

好主意。谢谢你。如果我理解正确，重载的控制器构造函数（如 repository pattern 中所示，应该解决依赖关系问题，只要控制器不依赖于存储整个类对象。