您将如何使用带有ASP.Net成员资格的实体框架(1.0)? [英] How would you use Entity Framework (1.0) with ASP.Net Membership?

问题描述

我正在尝试为使用ASP.Net成员身份进行用户身份验证的应用程序设计实体模型.在我创建的大多数数据库模式中，记录通常最终会通过aspnet_users表上的UserId字段与用户相关.过去，这对我来说还算不错，但是现在我正在使用EF，因此在弄清楚如何从实体中引用用户方面遇到了一些概念上的问题.

I'm trying to design an entity model for an application that uses ASP.Net membership for it's user authentication. In most of the database schemas I create, records typically end up related to users via the UserId field on the aspnet_users table. That's worked fine for me in the past, but now that I'm using EF, I'm having some conceptual issues with figuring out how I'm going to reference the user from an entity.

例如，假设我们有一个包含"postedBy"属性的"post"实体.我希望能够使用诸如post.user.username之类的内容来获取创建此帖子的用户的用户名，但是我担心基于aspnet_user表创建实体，因此担心创建一个让我们对数据库进行更改时，我绕过了Membership类.

For example, let's say we have a "post" entity that contains a "postedBy" property. I'd LIKE to be able to do get the username of the user that created this post with something like post.user.username, but I'm wary of creating an entity based on the aspnet_user table for fear of creating a model that let's me bypass the Membership class when making changes to the database.

我考虑过仅将post.userId字段保留为guid，然后要求任何需要知道用户名的代码都使用该guid来从Membership类中获取用户，但这似乎是不合格的".

I've considered just leaving the post.userId field as a guid and then requiring that any code that needs to know the username use that guid to get the user from the Membership class, but that seems "ineligant".

有人对与Membership集成的实体模型设计有任何建议吗?我会合理地使用只读"用户实体.

Does anyone have any recommendations for entity model designs that integrate with Membership? I'd be reasonably happen with a "read-only" user entity.

推荐答案

我的建议是:不要."

My advice is: "Don't."

让我更具体些.

使用UserId 作为映射的外键，通常不将您的实体模型与ASP.NET成员关系联系在一起，而是将其与SQL成员资格提供程序联系起来.如果您随后要使用域身份验证或OpenID，会发生什么情况?

Using UserId as a mapped, foreign key ties your entity model not to ASP.NET Membership in general, but to the SQL Membership Provider in general. What happens if you then want to use domain authentication or OpenID?

请不要误解:将数据库引用与外键绑定在一起的正确率是99.9％.哎呀，您甚至可以在这里做，但不要将其映射到您的实体模型中.您需要在成员资格提供程序和您自己的数据之间保持逻辑隔离.您可以通过EF访问数据.您可以通过成员资格API访问成员资格数据.由于您恰巧正在使用SQL成员资格提供程序，因此它们恰好位于同一数据库中，这是一个实现细节.

Don't get me wrong: 99.9% of the time it's correct to tie DB references together with a foreign key. Heck, you could even do it here, but don't map it into your entity model. You need to keep a wall of logical separation between membership providers and your own data. You access your data through the EF. You access membership data through the membership API. The fact that they happen to live in the same DB because you happen to be using the SQL membership provider is an implementation detail.

更新:我在 查看全文