Customizing ASP.NET Membership and Profile: What Goes Where?
No any feature introduced in ASP.NET 2.0 is the use of the “provider model” to provide maximum flexibility and extensibility to your Web applications. Using the provider model, developers can easily extend the capabilities provided by the ASP.NET 2.0 runtime, in many different ways. For example, you can extend the provider model to store the membership information for your Web site users in a custom data store, rather than the default SQL Server Express 2005 database.
I have come across to an article in which the author shows his experience in customizing the membership in asp.net. Please look at the following how he experienced the application.
Recent, I start playing the Membership class but not touching the Profile class yet. I search a lot and a question comes up to my mind. The standard Membership and its related table does not fits my DB and application design( as this is usual case I think), so I search around and thinking that i should implement the Profile or extend the Membership. Well, I got an answer after searching, I should implement Profile as itis the easier step.
The following is copying from Kirk Allen Evans’ Blog in MSDN blog
I have been working with two separate customers over the past few days on the same problem. Both have an existing web application that they are migrating to ASP.NET 2.0. They both wrote their own authentication functionality, and are now considering how to leverage the existing store with ASP.NET 2.0 Membership.
Consider a table that looks something like this:
UserID
int
UserName
nvarchar(50)
PasswordHash
nvarchar(50)
OfficePhone
nchar(10)
CellPhone
nchar(10)
Pager
nchar(10)
Obviously, this looks a lot different than the schema for Membership that is created when you run aspnet_regsql. If you want to retrofit your existing table into the Membership system, do you create a custom MembershipUser type and expose the OfficePhone, CellPhone, and Pager values as public properties, or do you leverage the Profile system instead?
You could extend the MembershipUser class and expose a few properties, but that ties your application to that specific provider. For instance, any time you want to access the Pager value, you would need to do something like:
CustomMembershipUser u = Membership.GetUser(”bob”,true) As CustomMembershipUser;
if(null != u)
{
TextBox1.Text = u.Pager;
}
You would not only have to cast to your custom MembershipUser type, but you also need to check to see if the correct type is returned, lest someone switch to a different provider. This is the real aversion I have to extending MembershipUser, since your application cannot easily take [...]
Read more at kenlin@HK [MVP]