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