您将如何将实体框架 (1.0) 与 ASP.Net 成员资格结合使用？
我正在尝试为使用 ASP.Net 成员身份进行用户身份验证的应用程序设计一个实体模型。在我创建的大多数数据库模式中，记录通常最终通过 aspnet_users 表上的 UserId 字段与用户相关。这在过去对我来说效果很好，但现在我使用 EF，在弄清楚如何从实体引用用户时遇到了一些概念问题。
例如，假设我们有一个包含“postedBy”属性的“post”实体。我希望能够使用 post.user.username 之类的内容获取创建此帖子的用户的用户名，但我对基于 aspnet_user 表创建一个实体持谨慎态度，因为担心创建一个模型让我们我在更改数据库时绕过了 Membership 类。
我考虑过将 post.userId 字段保留为 guid，然后要求任何需要知道用户名的代码使用该 guid 从 Membership 类中获取用户，但这似乎“不合格”。
有人对与会员资格集成的实体模型设计有任何建议吗？我会合理地使用“只读”用户实体。
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.
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.
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".
Does anyone have any recommendations for entity model designs that integrate with Membership? I'd be reasonably happen with a "read-only" user entity.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的建议是：“不要。”
让我说得更具体一些。
使用 UserId 作为映射的外键不会将您的实体模型与一般的 ASP.NET 成员资格联系起来，而是与一般的 SQL 成员资格提供者联系起来。如果您想使用域身份验证或 OpenID，会发生什么情况？
不要误会我的意思：99.9% 的情况下，将数据库引用与外键绑定在一起是正确的。哎呀，您甚至可以在这里执行此操作，但不要将其映射到实体模型中。您需要在会员提供商和您自己的数据之间保持逻辑隔离墙。您通过 EF 访问您的数据。您可以通过会员 API 访问会员数据。事实上，由于您恰好使用 SQL 成员身份提供程序，它们恰好位于同一个数据库中，这是一个实现细节。
更新：我在 一篇博客文章。
My advice is: "Don't."
Let me be more specific.
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?
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.
Update: I've expanded upon this idea in a blog post.