Associating extra information with ASP.NET MVC Membership

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

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.

Answer 2

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.

Answer 3

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.