Before you start using profiles, you should know some limitations of the SqlProfileProvider shipped with ASP.NET. First of all, it can become a performance-bottleneck. Each time you query profile information for a user, the profile API retrieves all of the user profile information from the underlying database (a roundtrip to SQL Server). However, after that you are free to process the requested information as long as you don’t post back your page to the server. When you modify profile information, another roundtrip is taken to the server.
Given these facts, you should store relatively small amount of information in user profiles. Another problem is that this information is serialized as clear text (or binary data/XML) but in any way, it’s not encrypted. So you should never include sensitive data in user profiles. Good news that your custom classes (as long as they are serializable) can be stored in profiles. I’ve kept the worst to the last: all profile information is stored in two cells for each user. In the first, all the names of the properties, in the second, all their values. So it will be very hard to share profile information with a desktop application, for example.
There are two ways to overcome these limitations: you can use custom data access components, thereby evading the use of the whole profile system. This offers more flexibility, and it’s easier. The other approach is to extend the profile system by creating a custom profile provider. You’d use this latter method in the following scenarios:
- You’d like to store profile information in a database other than SQL Server.
- You’d like to maintain cross-application compatibility.
- You’d like to implement additional logic for working with profile data. For example, you’d like to validate, encrypt/decrypt, cache, etc.
As I mentioned before, you can use your custom types when you’re working with profiles. This is a great thing, and you should live with it. Build your own custom classes for dealing with complex information, such as addresses, and use it instead of grouping related profile properties.
You can even add profile properties for unauthenticated users. To do so, mark the properties you’d like to expose for these users with the allowAnonymous=”true” tag. Also, you need to define the anonymousIdentification element in the system.web section, and set its enabled attribute to true. Then anonymous users can use the profile system. The connection is maintained by using a member of the cookieLess enumeration.
Now rises the question: what if an unauthenticated user using the profile system logs in/registers. The answer is to define the following method in global.asax:
public void Profile_OnMigrateAnonymous(object sender, ProfileMigrateEventArgs e)
ProfileCommon theProfile = Profile.GetProfile(e.anonymousID);
Profile.Name = theProfile.Name;
Assuming you have only one profile property, called Name, you’d like to save to the new profile.