Identity Owin 是否需要延迟加载? [英] Does Identity Owin require LazyLoading?

查看:24
本文介绍了Identity Owin 是否需要延迟加载?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

tl;dr:Identity 似乎要求不禁用 LazyLoading;这是真的吗?最干净的解决方法是什么?

tl;dr: Identity seems to require that LazyLoading NOT be disabled; is this true, and what is the cleanest workaround?

我使用 EntityFramework 6.0.2、Identity EntityFramework 1.0.0 和 Identity Owin 1.0.0 对一个简单的 C# ASP.NET 4.5.1 MVC-5 Web 应用程序进行了一些基本的 AB 测试,看来 Owin 需要那个懒惰的ApplicationContext 构造函数中未禁用加载.

I did some basic A-B testing on a simple C# ASP.NET 4.5.1 MVC-5 web application using EntityFramework 6.0.2, Identity EntityFramework 1.0.0, and Identity Owin 1.0.0 and it appears that Owin requires that lazy loading is NOT disabled in the ApplicationContext constructor.

要复制该问题,只需使用 Visual Studio 2013 制作一个快速的 MVC 应用程序,使用 MVC 模板,将所有内容保留为默认值,但取消注释该行:'app.UseGoogleAuthentication();'在 App_Start/Startup.Auth.cs 中.运行应用程序并使用 Google 登录,完成它带您进入的简短注册页面并转到帐户/管理.您应该会在底部看到 2 个 Google 按钮.停止应用.

To replicate the issue just make a quick MVC app using Visual Studio 2013, use the MVC template, leave everything at the defaults except uncomment the line: 'app.UseGoogleAuthentication();' in App_Start/Startup.Auth.cs. Run the app and use Google to login, complete the abbreviated registration page it takes you to and go to account/manage. You should see 2 buttons for Google at the bottom. Stop the app.

现在转到 ApplicationContext.cs 并更改构造函数,如下代码片段所示:

Now go to ApplicationContext.cs and change the constructor as shown in this code snippet:

public ApplicationContext() : base("DefaultConnection") { } //Works!

public ApplicationContext() : base("DefaultConnection") 
{
    this.Configuration.LazyLoadingEnabled = false;
} //Does not work

重试测试.只有 1 个 Google 按钮应该可见.使用 LazyLoadingEnabled = false 时,不会加载用户角色、登录名(也有声明).

Retry the test. Only 1 Google button should be visible. With LazyLoadingEnabled = false the User Roles, Logins (poss Claims also) aren't loaded.

我的理论是,这是 Microsoft 的一项监督/未来功能",因为 Identity EntityFramework 和 Identity Owin 都是 1.0.0 版.

My theory is that this is a Microsoft oversight/'future feature' as Identity EntityFramework and Identity Owin are both version 1.0.0.

我的问题是,这个测试能否得到证实,最干净的工作是什么?

My question is, can this test be confirmed, and what is the cleanest work around?

出于我的目的,当我想使用它时,我将只使用 .ToList() 和其他方法来强制 EagerLoading.我并不是真的需要禁用 LazyLoading,如果您想始终使用预先加载,它只是一种更安全的编码方式.即你错过了一个地方,它进入了生产环境,并且你有一个很好的错误,在某些视图中,你正在遍历一个模型,对于 Model.x.y y == null 并且数据库连接已经被释放.

For my purposes I will just use .ToList() and other methods for forcing EagerLoading when I want to use it. I don't truly need LazyLoading disabled, it's just a safer way to code if you want to always use eager loading. i.e. you miss one spot, it makes it to production, and you have a nice bug where in some View you are iterating through a Model and for Model.x.y y == null and the database connection has been disposed.

让我们不要讨论 Identity 与其他(更强大的)方法,或者:

Let's not get into Identity vs. other (more robust) methods, or:

using (DatabaseContext) { //Database query } 

或在每个方法上调用 dispose 与让连接自动处理.在这种情况下,您必须使用 Identity Owin,并尽快处理所有数据库调用.应该有什么我遗漏了,或者身份现在真的不完整.

or calling dispose on every method vs letting the connection be disposed automatically. This is a scenario where you have to use Identity Owin, and dispose of all database calls ASAP. There ought to be something I'm missing, or maybe Identity really is just that incomplete right now.

推荐答案

是的,这是我们在 2.0.0-alpha1 版本中修复的错误.事先明确禁用延迟加载,EF 不会自动加载关联的用户实体(登录/声明/角色)

Yes this was a bug we have fixed in the 2.0.0-alpha1 release. With lazyLoading explicitly disabled prior, EF would not load the associated user entities automatically (logins/claims/roles)

这篇关于Identity Owin 是否需要延迟加载?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆