Question

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?

Answer 1

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.