views:

147

answers:

2

I have a basic app using the ASP.NET membership provider. By default, you can use a few fields such as username\password\remember me. How do I add to the asp.net membership provider so I can add an additional field "address" in the register section and have it save to the database. I currently see the following when creating a user in the account model:

public MembershipCreateStatus CreateUser(string userName, string password, string email)
        {
            if (String.IsNullOrEmpty(userName)) throw new ArgumentException("Value cannot be null or empty.", "userName");
            if (String.IsNullOrEmpty(password)) throw new ArgumentException("Value cannot be null or empty.", "password");
            if (String.IsNullOrEmpty(email)) throw new ArgumentException("Value cannot be null or empty.", "email");



            MembershipCreateStatus status;
            _provider.CreateUser(userName, password, email, null, null, true, null, out status);


            return status;
        }

In the create user function, I also want to save the user's "address".

In the register.aspx I added a the following:

 <div class="editor-label">
                  <%: Html.LabelFor(m => m.Address) %>
                </div>
                <div class="editor-field">
                  <%: Html.TextAreaFor(m => m.Address) %>
                </div>

Any ideas?

A: 

You're going to want to use the Profile Provider for this, thats what it was meant for. If you modify the membership provider to add the additional field it will break the provider contract and you won't be able to switch to another in the future.

Here is the profile provider: http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
More info: http://msdn.microsoft.com/en-us/library/014bec1k.aspx

If you are using the sql membership provider than you probably have all the table structures installed to support the profile provider as well.

jwsample
+1  A: 

As jwsample noted, you can use the Profile Provider for this.

Alternatively, you could create your own table(s) that store additional user-related information. This is a little more work since you're on the hook for creating your own tables and creating the code to get and save data to and from these tables, but I find that using custom tables in this way allows for greater flexibility and more maintainability than the Profile Provider (specifically, the default Profile Provider, SqlProfileProvider, which stores profile data in an inefficient, denormalized manner).

Take a look at this tutorial, where I walk through this process: Storing Additional User Information.

Scott Mitchell