将额外信息与 ASP.NET MVC 成员资格相关联

发布于 2024-07-29 16:52:08 字数 185 浏览 3 评论 0原文

我不确定是否应该使用 MVC 执行此操作,但我很好奇在使用会员资格提供程序时向 ASP.NET 用户帐户添加额外信息的推荐方法是什么? 以及如何将此用途与其他实体相关联。

通常我不关心配置文件,而是更喜欢向仅引用 USERID 的表添加额外信息。 这对于 ASP.NET MVC 方法来说是好/坏/可接受的,或者什么是替代方案?

I am not sure if I should do this any different with MVC, but I am curious what is the recommended approach for adding extra info to a ASP.NET User account when using the Membership provider? Also how to associate this use with other entities.

Normally I don't bother with the profiles, and prefer to add extra information to a table that simply references the USERID. Is this good/bad/acceptable for the ASP.NET MVC approach, or what would would be an alternative?

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

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

发布评论

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

评论(3

困倦 2024-08-05 16:52:08

这是一个很好的问题,也是我一直在思考的一个问题。 我认为有以下三种基本方法:

  1. 使用配置文件提供程序 - 这使得添加属性变得很容易,但执行诸如生成用户表之类的操作却很麻烦,特别是当您需要应用过滤器/搜索时。 API 只是不能解决这个问题。

  2. 添加一个新表(或扩展现有表),然后加入该表。 然后,您需要编写自己的方法来获取自定义数据。

  3. 编写您自己的会员资格提供程序来扩展 MembershipProvider 类。

对于我的上一个项目,我使用了后一种方法 - 我编写了一个非常快速的 SQL 提供程序,它只实现了创建用户、身份验证和更改密码所需的基本要素。 对于其余的虚拟方法,我只是抛出了一个 NotImplementedException

然后,我添加了一个新类,该类添加了我需要的额外属性,并使其可以通过传入标准 MembershipUser 来实例化。 像这样的事情:

public static CustomMember GetMember(MembershipUser user)
{
    // Get your custom member
}

这样你就可以使用标准的 MembershipUser 来完成大多数事情,但是如果你需要获得有关当前用户的更多详细信息,你可以这样做:

MembershipUser user = Membership.GetUser();
CustomMember member = CustomMember.GetMember(user);

不过,我有兴趣看看其他人的方法是什么。

It's a good question, and one I've struggled with. I think there are three basic approaches;

  1. Use a Profile provider - this makes it easy to add properties but cumbersome to do things like generating a table of users, especially if you need to apply filters / searches. The API just doesn't cut it.

  2. Add a new table (or extend the existing table) and then join this. You'll then need to write your own methods to get custom data back.

  3. Write your own Membership provider that extends the MembershipProvider class.

For my last project I used the latter approach - I wrote a very quck SQL provider that only implemented the bare essentials required for creating users, authentication and changing passwords. For the rest of the virtual methods I just threw a NotImplementedException.

I then added a new class that added the extra properties I needed and made it so it could be instantiated by passing in a standard MembershipUser. Something like this:

public static CustomMember GetMember(MembershipUser user)
{
    // Get your custom member
}

That way you can use the standard MembershipUser for most things but if you need to get more details about the current user you do stuff like this:

MembershipUser user = Membership.GetUser();
CustomMember member = CustomMember.GetMember(user);

I'd be interested to see what other peoples' approaches are, though.

何其悲哀 2024-08-05 16:52:08

您使用 MVC 的事实不应对您处理成员资格和“用户数据”的方式产生任何重大影响。

我通常还避免使用 ASP.NET 配置文件,实际上也避免使用默认的 ASP.NET 成员资格,而更喜欢滚动我自己的成员资格提供程序和“配置文件”架构,链接到我现有的用户表。

如果您对有关客户会员提供商的更多信息感兴趣,请发表评论。

The fact that you are using MVC should not have any significant impact upon the way you deal with membership and 'user data'.

I also typically avoid ASP.NET Profiles, and indeed the default ASP.NET Membership, preferring to roll my own membership provider and 'profile' schema, linked to my existing user table.

Post a comment if you are interested in further information on customer membership providers.

摘星┃星的人 2024-08-05 16:52:08

我希望看到更多关于这个主题和人们所做的事情的反馈。 我目前在 ASP.NET MVC 应用程序中使用标准 ASP.NET 成员资格/角色提供程序系统,但不太喜欢它。

我的方法是更改​​ aspnet_users 表并添加一大堆额外的列; CompanyId、StreetAddress 等。

我在标准配置文件中存储了用户如何使用网站的配置文件设置; 他们使用什么主题,分页列表显示多少记录等等。

正如大多数人发现的那样,从配置文件中获取信息是一件痛苦的事情,并且由于序列化,我在大型系统中阅读的内容可能会成为性能瓶颈。

我倾向于在我的表上滚动以更好地匹配我的应用程序架构,实现自定义 SQL 提供程序,然后考虑在 ASP.NET MVC 中编写一些额外的安全属性(如果需要)。

I'd love to see a lot more feedback on this topic and what people do. I am currently using the standard asp.net membership / role provider system in an asp.net mvc app and don't like it much.

My approach was to alter the aspnet_users table and add on a whole bunch of extra columns; CompanyId, StreetAddress etc.

I stored users profile settings for how they use the website in the standard profile; what theme they use, how many records the paged lists display and other things.

As most people find, getting information in and out of profile is a pain and from what I'm reading in large systems can become a performance bottleneck due to the serialisation.

I am leaning towards rolling on my tables that better match my application schema, implementing a custom sql provider and then looking at writing some additional security attributes in asp.net mvc if I need them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文