tl；dr：标识似乎要求不禁用LazyLoading；这是真的吗？最干净的解决方法是什么？
我使用EntityFramework 6.0.2、Identity EntityFramework 1.0.0和Identity Owin 1.0.0在一个简单的C#ASP.NET 4.5.1 MVC-5 web应用程序上进行了一些基本的A-B测试，Owin似乎要求ApplicationContext构造函数中不禁用延迟加载。
要复制此问题，只需使用Visual Studio 2013制作一个快速MVC应用程序，使用MVC模板，将所有内容保留为默认值，只需取消注释行："app.UseGoogleAuthentication()；"在App_Start/Startup.Auth.cs中。运行应用程序并使用谷歌登录，完成它带你进入的缩写注册页面，然后转到帐户/管理。你应该在底部看到两个谷歌按钮。停止应用程序。
现在转到ApplicationContext.cs并更改构造函数，如下代码片段所示：
public ApplicationContext() : base("DefaultConnection") { } //Works!
public ApplicationContext() : base("DefaultConnection")
{
this.Configuration.LazyLoadingEnabled = false;
} //Does not work
请重试测试。只能看到一个谷歌按钮。如果LazyLoadingEnabled=false，则不会加载用户角色、登录名(也包括poss声明)。
我的理论是，这是微软的一个监督/"未来功能"，因为Identity EntityFramework和Identity Owin都是1.0.0版本。
我的问题是，这个测试能被证实吗？周围最干净的工作是什么？
出于我的目的，当我想使用EagerLoading时，我只会使用.ToList()和其他方法来强制它。我并不真的需要禁用LazyLoading，如果你想总是使用热切加载，这只是一种更安全的编码方式。即，你错过了一个位置，它进入了生产阶段，并且你有一个很好的错误，在某些视图中，你正在迭代一个模型，对于Model.x.y y==null，数据库连接已经被处理。
我们不要讨论Identity与其他(更稳健)方法的比较，或者：
using (DatabaseContext) { //Database query }
或者在每个方法上调用dispose，而不是让连接自动处理。在这种情况下，您必须使用Identity Owin，并尽快处理所有数据库调用。我应该缺少一些东西，或者也许身份现在真的那么不完整。
是的，这是我们在2.0.0-alpha1版本中修复的一个错误。在之前明确禁用lazyLoading的情况下，EF不会自动加载关联的用户实体(登录/声明/角色)