为了让这个问题简单化，我将描述更高层次的问题，然后在需要时讨论任何实现细节。

我在开发中的应用程序中使用 ASP.NET 标识。在一系列请求的特定场景中，UserManager 首先获取当前用户(至少一个 FindById 请求)，从中获取用户。在后续请求中，我更新了由 U​​serManager.Update 保存的关于该用户的信息，我可以看到数据库中保存的更改。

这里的问题是，在进一步的后续请求中，从 FindById 获取的用户对象没有更新。这很奇怪，但可能与我不明白的 UserManager 中的缓存有关。但是，当我跟踪数据库调用时，我发现 UserManager 确实正在向数据库发送 sql 请求以获取用户。

这就是它变得非常奇怪的地方 - 即使数据库被确认是最新的，UserManager 仍然以某种方式从这个过程中返回一个旧对象。当我自己运行直接跟踪到数据库的完全相同的查询时，我得到了预期的更新数据。

这是什么黑魔法？

很明显，有些东西缓存在某个地方，但为什么它会查询数据库，而忽略它获得的更新数据呢？

示例

这个下面的例子更新了数据库中对 Controller 操作的每个请求的预期的一切，当 GetUserDummyTestClass 在 UserManager 的另一个实例上调用 findById 时，我可以跟踪 sql 请求，并且可以直接测试这些到数据库并验证他们返回更新的数据。但是，从同一行代码返回的用户对象仍然具有旧值(在这种情况下，应用程序启动后的第一次编辑，无论调用了多少次测试操作)。

Controller

public ActionResult Test()
{
    var userId = User.Identity.GetUserId();
    var user = UserManager.FindById(userId);

    user.RealName = "name - " + DateTime.Now.ToString("mm:ss:fff");
    UserManager.Update(user);
    return View((object)userId);
}

Test.cshtml

@model string

@{
    var user = GetUserDummyTestClass.GetUser(Model);
}

@user.RealName;

GetUserDummyTestClass

public class GetUserDummyTestClass
{
    private static UserManager<ApplicationUser> _userManager;

    private static UserManager<ApplicationUser> UserManager
    {
        get { return _userManager ?? (_userManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()))); }
    }

    public static ApplicationUser GetUser(string id)
    {
        var user = UserManager.FindById(id);
        return user;
    }
}

更新

正如 Erik 所指出的，我不应该使用静态 UserManagers。但是，如果我将 GetUserDummyTest 中的 UserManager 绑定(bind)到 HttpContext(根据 HttpRequest 保留它)以防我想在请求期间多次使用它，它仍然缓存它通过 Id 获取的第一个 User 对象，并忽略任何更新来自另一个 UserManager。因此表明真正的问题确实是我使用了两个不同的 UserManagers 作为 trailmax 建议，并且它不是为这种用法而设计的。

在我上面的示例中，如果我将 GetUserDummyTestClass 中的 UserManager 保留在 HttpRequest 上，添加一个更新方法并仅在 Controller 中使用它，一切都会按预期正常工作。

因此，如果要得出结论，如果我想在 Controller 范围之外使用来自 UserManager 的逻辑，我必须将 UserManager 实例全局化到一个适当的类中，我可以在其中绑定(bind)实例到 HttpContext，如果我想避免为一次性使用创建和处置实例？

更新 2

进一步调查，我意识到我确实打算为每个请求使用一个实例，并且实际上已经为 Startup.Auth 中的 OwinContext 设置了这个实例，之后可以像这样访问:

using Microsoft.AspNet.Identity.Owin;

// Controller
HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>()

// Other scopes
HttpContext.Current.GetOwinContext().GetUserManager<ApplicationUserManager>()

从所提供的默认 AccountController 的设置来看，这实际上是非常明显的，但我猜上面描述的相当奇怪和意外的行为被证明是相当分散注意力的。尽管如此，了解这种行为的原因还是很有趣的，即使使用 OwinContext.GetUserManager 不再是问题。

最佳答案

你的问题是你使用了两个不同的 UserManager 实例，看起来它们都是静态定义的(这在 Web 应用程序中是一个巨大的禁忌，因为它们在系统的所有线程和用户之间共享并且不是线程安全的，你甚至不能通过锁定它们来使它们成为线程安全的，因为它们包含特定于用户的状态)

将您的 GetUserDummyTestClass 更改为:

private static UserManager<ApplicationUser> UserManager
{
    get { return new UserManager<ApplicationUser>(
          new UserStore<ApplicationUser>(new ApplicationDbContext())); }
}

public static ApplicationUser GetUser(string id)
{
    using (var userManager = UserManager)
    {
        return UserManager.FindById(id);
    }
}

关于c# - .Net Identity 中 UserManager 的奇怪行为，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25701942/