Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Associating extra information with ASP.NET MVC Membership

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?

like image 684
Dkong Avatar asked Jul 29 '09 08:07

Dkong


2 Answers

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.

like image 41
David Christiansen Avatar answered Sep 20 '22 15:09

David Christiansen


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.

like image 109
Dan Diplo Avatar answered Sep 17 '22 15:09

Dan Diplo