我正在尝试为使用ASP.Net成员资格进行用户身份验证的应用程序设计实体模型。在我创建的大多数数据库模式中，记录通常最终通过aspnet_users表上的UserId字段与用户相关。这在过去对我来说很好用，但是现在我正在使用EF，我有一些概念性的问题，弄清楚我将如何从实体引用用户。
例如，假设我们有一个包含“postedBy”属性的“post”实体。我想能够用post.user.username之类的东西来获取创建这篇文章的用户的用户名，但是我担心基于aspnet_user表创建一个实体，因为担心创建一个让我们的模型在对数据库进行更改时，我绕过了Membership类。
我考虑过将post.userId字段保留为guid，然后要求任何需要知道用户名的代码使用该guid从Membership类中获取用户，但这似乎是“无益的”。
是否有人对与会员资格整合的实体模型设计有任何建议？我会合理地使用“只读”用户实体。
答案 0 :(得分：12)
我的建议是：“不要。”
让我更具体一点。
使用UserId 作为映射的外键将您的实体模型与一般的ASP.NET成员资格绑定在一起，而不是与SQL成员资格提供程序绑定。如果您想使用域身份验证或OpenID，会发生什么？
不要误解我的意思：99.9％的时候将DB引用与外键绑定在一起是正确的。哎呀，你甚至可以在这里做，但不要把它映射到你的实体模型。您需要在成员资格提供者和您自己的数据之间保持逻辑分离。您可以通过EF访问您的数据。您可以通过成员资格API访问会员数据。因为您碰巧使用SQL成员资格提供程序而碰巧住在同一个数据库中这一事实是一个实现细节。
更新：我在a blog post中扩展了这个想法。