我一直在思考如何解决在使用 ASP.NET MVC 时实现基于 ID 的用户系统的问题。我的目标，很像 StackOverflow 的系统，如下：
我想尽可能地避免返工，所以我一开始想使用会员、角色和（也许）个人资料提供者，但我发现它们是基于用户名的。我想通过使用用户名字段来存储 ID 并在基于密码的方法等上抛出 UnsupportedException 来适应 SqlMembershipProvider，以便能够使用其他系统。但它感觉笨拙和笨拙（如果可能的话）。
另一方面，也许我应该建立自己的用户系统，但我不确定即使我不能使用提供程序，我仍然可以使用 MVC 的一些功能（将我的代码插入到 MVC 的某个地方，我可以想到我头顶的 AuthorizeAttribute）。
所以我想知道是否有人遇到过同样的设计问题，以及他们想出了什么解决方案。
越详细越好！
我必须为客户建立一个快速的会员系统，他们有一些要求不允许我立即使用内置，也没有时间构建他们想要的东西。我计划最终推出一个完整的会员管理系统，但和你一样，我现在需要一些东西。我采用了以下计划，最终，我可以将内置提供程序换成我自己的 - 时间限制和截止日期很糟糕：
我有自己的个人用户表 (PT) - MembershipId、用户名、电子邮件、多余的个人资料信息。这是应用程序用于任何用户信息的内容。它是一个类，它可以被缓存，保存在 http 上下文中，cookie - 但是你想处理你的用户信息。
然后，我为身份验证、授权和角色设置了 SqlProfileProvider。我不使用配置文件提供程序（即使是琐碎的设置），因为它在 MVC 中很痛苦。我没有对内置提供程序进行任何更改。这就是我用于身份验证和授权的内容。
创建用户时，我的代码执行以下操作：
登录时，我从 PT 获取 MembershipId，使用 MembershipId 和密码验证 Membership，我就完成了。
删除用户时，我执行以下操作：
它按预期工作:)
一些事情： User.Identity.Name 将是 MembershipId (Guid)。这用于登录和角色管理。我的 PT 是保存用户信息（保存密码）的地方。我可以更改用户名、电子邮件等，而不会影响成员资格或角色，因为成员资格是基于 PT 的 PrimaryKey。
登录需要额外的数据库命中，因为您需要查询 PT 以获取 MembershipId 进行验证（您可以缓存）。
内置的身份验证系统非常繁重 - 如果您查看存储过程，您会看到它为验证用户所经历的所有环节。我建议最终远离它。但在紧要关头，它做得很好——如果你没有百万用户，我认为这不是问题。
我没有考虑过 OpenId，我不确定您将如何集成它，尽管我认为您可能可以做与上述相同的事情，而不是验证实际凭据（在它们返回经过验证的 OpenId 表单之后）只需登录使用 MembershipId 的用户（不要验证 Membership）。
对我来说，这背后的要点是该应用程序使用自定义用户模型，允许更改用户名、电子邮件、姓名等。而不影响身份验证和角色。当我准备好更改为完整的系统时，我可以更改它而不用担心对应用程序的影响。
放弃使用 SqlMembershipProvider。它真正为您提供的唯一东西是开箱即用的管理界面。它带来的其余部分将是令人讨厌的。
只需使用 sql 成员资格提供程序并添加一个存储过程来更改数据库级别的用户名。