帐户配置文件 MVC .NET

发布于 2024-12-18 20:01:56 字数 235 浏览 3 评论 0原文

我一直在研究如何在 .NET MVC 中进行自定义 profileprovider。 看起来相当复杂。还有其他选择吗? 这是我最关心的问题,为什么人们要费心使用客户资料提供程序?如果他们想要有关用户的额外信息,为什么不创建另一个与 aspnet_Users 具有 OneToOne 关系的表,并以 userId 或 userName 作为外键?

请澄清。我正在尝试实现用户配置文件功能,但我不想走上错误的道路。

谢谢 总干事

I have been doing some research about how to do custom profileprovider in .NET MVC.
It seems pretty complicated. Is there any other alternative?
And this is my major concern, why do ppl bother using customer profileprovider? If they want extra information about a user, why don't they just make another table with OneToOne relationship with aspnet_Users with userId or userName as the foreign key?

Please clarify. I'm trying to implement user profile functionality, but I don't wanna go down the wrong path.

Thanks
DG

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

指尖微凉心微凉 2024-12-25 20:01:56

(我不确定这是否有助于谈论自定义配置文件提供程序..除非我被误解了...)


IMO,无论你做什么..避免(烘焙的in) ASP.NET 会员资格不惜一切代价!它设计得太过分了,你会想用钝勺子刺进自己的眼睛:(

相信我,避免它。

为什么:我应该为 ASP .NET MVC 使用内置成员资格提供程序应用程序?

那么..我们可以做什么呢?

使用您自己的用户名/密码并利用内置的表单身份验证就这么简单,对于我自己来说,我不是一个粉丝。在我自己的数据库中存储任何密码..所以我更喜欢使用 Facebook、Twitter 或 OAuth 作为 我的身份验证机制 ..这意味着我完成了一个简单的、基本的、自定义的用户类

。 href="https://github.com/PureKrome/RavenOverflow/tree/master/Code/RavenOverflow.Web/Models/Authentication" rel="nofollow noreferrer">创建我自己的自定义 IPrincipal 和 IIdentity 因为我想要在 cookie 中存储更多信息,当一个人通过身份验证时,Forms Auth 将创建该 cookie。这有助于保持控制器中的代码更干净、更简单。

例如,我将经过身份验证的人的 userId 存储在加密的 cookie 中。 (默认选项是仅存储名称)。我还存储了一两件以上的东西..但你明白了。这样,我并不总是需要访问数据库来检索任何用户数据或将这些垃圾存储在会话中。

通过您自己的卷,您可以创建额外的元数据..并拥有额外的个人资料数据。同一张桌子?额外的桌子?谁在乎......这是一个稍后做出的决定(并且很容易解决)。让你的模型正确,IMO :) 然后一旦你锁定了你的模型,你现在知道什么是必需的,什么是可选的.. 然后你可以做出一些数据库决策。

总结

  1. 避免内置的 ASP.NET 会员资格废话
  2. 自行开发..并保持简单。
  3. 如果您感觉很先进,还可以推出自己的 IPrincipalIIdentity 来真正震撼您的世界。

(I am not sure if this helps talk about custom profile providers.. unless I'm misunderstood...)


IMO, what ever you do .. avoid (the baked in) ASP.NET Membership at any cost! It's so over engineered, you'll want to stab yourself in the eye with a blunt spoon :(

Trust me, avoid it.

Why: Should I use the built-in membership provider for an ASP .NET MVC application?

So .. what can we do instead?

It's just so simple to roll your own Username/Password and leverage the built in Forms Authentication. For myself, I'm not a fan of storing -any- passwords in my own database .. so I prefer to use Facebook, Twitter or OAuth as my mechanism for authentication .. which then means I finish up with a simple, basic, custom user class.

I also create my own custom IPrincipal and IIdentity because I want to store a bit more info in the cookie, which Forms Auth creates when a person has been authenticated. This then helps keep my code in my Controllers cleaner and way simpler.

For example, I store the userId of the authenticated person in an encrypted cookie. (the default option is to only store a Name). I also store one or two more things .. but you get the idea. This way, I don't always have the hit the DB to retrieve any user data OR store this crap in a session.

With a roll your own, you can create extra meta data .. and have that extra profile data. Same table? extra table? Who cares ... that's a decision to make way later (and EASY to solve). Get your model right, IMO :) Then once you've locked down your model, you now know what's required and what's optional .. and you can make some DB decisions then.

Summary

  1. Avoid the built in ASP.NET Membership crap
  2. Roll your own .. and keep it simple.
  3. If you're feeling advanced, also roll your own IPrincipal and IIdentity to really rock your world.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文