我一直在研究如何在 .NET MVC 中自定义 profileprovider。看起来相当复杂。还有其他选择吗？这是我主要关心的问题，为什么人们要费心使用客户资料提供者？如果他们想要关于用户的额外信息，为什么不直接使用 aspnet_Users 与 userId 或 userName 作为外键创建另一个具有 OneToOne 关系的表？
请澄清。我正在尝试实现用户配置文件功能，但我不想走错路。
谢谢 DG
问问题
462 次
1 回答
1
（不确定这是否有助于谈论自定义配置文件提供者..除非我被误解了......）
IMO，无论你做什么..不惜一切代价避免（烘焙）！它的设计太过分了，你会想用钝勺戳自己的眼睛:(ASP.NET Membership
相信我。躲开它。
为什么：我应该为 ASP .NET MVC 应用程序使用内置的成员资格提供程序吗？
所以..我们能做些什么呢？
滚动您自己的用户名/密码并利用内置的Forms Authentication. 就我自己而言，我不喜欢在我自己的数据库中存储任何密码......所以我更喜欢使用 Facebook、Twitter 或 OAuth 作为我的身份验证机制......这意味着我完成了一个简单、基本、自定义用户类。
我还创建了自己的自定义 IPrincipal 和 IIdentity，因为我想在 cookie 中存储更多信息，当一个人通过身份验证时，Forms Auth 会创建这些信息。然后，这有助于使我的控制器中的代码更干净、更简单。
例如，我将经过身份验证的人的 userId 存储在加密的 cookie 中。（默认选项是只存储 a Name）。我还存储了一两件更多的东西..但你明白了。这样，我并不总是能够在数据库中检索任何用户数据或将这些废话存储在会话中。
通过自己的滚动，您可以创建额外的元数据（生日？妈妈的娘家姓？社会安全号码（笑话））......并拥有额外的个人资料数据。同桌？额外的桌子？谁在乎……这是以后让路的决定（而且很容易解决）。让你的模型正确，IMO :) 然后，一旦你锁定了你的模型，你现在就知道什么是必需的，什么是可选的......然后你可以做出一些数据库决定。
TLDR？?
- 避免内置的 ASP.NET Membership 废话
- 滚动你自己的..并保持简单。
- 如果你感觉很先进，也可以自己动手
IPrincipal，IIdentidy真正震撼你的世界。
GL HF，不要用钝勺子刺自己，在你的眼睛里！
于 2011-11-30T04:00:52.410 回答