views:

137

answers:

2

I've recently started tinkering with ASP.NET MVC, but this question should apply to classic ASP.NET as well. For what it's worth, I don't know very much about forms authentication and membership providers either.

I'm trying to write my own MembershipProvider which will be connected to my own custom user table in my database. My user table contains all of the basic user information such as usernames, passwords, password salts, e-mail addresses and so on, but also information such as first name, last name and country of residence.

As far as I understand, the standard way of doing this in ASP.NET is to create a user table without the extra information and then a "profile" table with the extra information. However, this doesn't sound very good to me, because whenever I need to access that extra information I would have to make one extra database query to get it.

I read in the book "Pro ASP.NET 3.5 in C# 2008" that having a separate table for the profiles is not a very good idea if you need to access the profile table a lot and have many different pages in your website.

Now for the problem at hand... As I said, I'm writing my own custom MembershipProvider subclass and it's going pretty well so far, but now I've come to realize that the CreateUser doesn't allow me to create users in the way I'd like. The method only takes a fixed number of arguments and first name, last name and country of residence are not part of them.

So how would I create an entry for the new user in my custom table without this information at hand in CreateUser of my MembershipProvider?

A: 

I agree with your analysis that you should keep both membership and profile information in the same table. Since you are correct that you are restricted by the number of parameters that CreateUser takes, you will need to design your field so that non-membership profile attributes are nullable. This does not mean that you will have required fields that are null in the database, however. Instead, you can you the below snippet:

string username = .../ retrieve username here

Membership.CreateUser(username , password, email);

ProfileBase newProfile = Profile.Create(username); //since the user has just been created, all properties will be blank

//set all entered properties
newProfile.SetPropertyValue("MyProp1", myProp1Value);
... 
newProfile.SetPropertyValue("MyPropN", myPropNValue);

newProfile.Save();

In this way, you leverage ASP.NET's membership providers to create the user and save profile data, but to your end user it is a single atomic operation.

MrGumbe
+1  A: 

I think you should go on with your approach and add a new function in your implementation, I mean, overload the CreateUser method and have a CustomMembershipUser (that extends the MembershipUser) as a parameter. In that way, before using the provider, cast it to your CustomMembershipProvider and use the overloaded method.

uvita
+1 - while I would have to say that a lot of caching can be done to aleviate load, if one is dead set against using a dead simple membership/profile strategy, overloading the xxxUser methods is the way to go.
Sky Sanders
Interesting... I saw a video tutorial where someone implements a custom MembershipProvider and in `CreateUser` he returns `null`. Is the return value not supposed to be used for anything?
Deniz Dogan