The heart of the new ASP.NET personalization service is the User Profile. A User Profile defines what kind of personal information your Web site needs. For example, you may want to know personal data about users of your Web site, such as name, gender, number of visits to the site, and so forth. User Profiles are also handy for storing user preferences for your site. For example, you might include a Theme as part of a personal profile so that users can tailor the pages to their particular tastes.
Once the personalization properties are defined in Web.Config, a component within .NET has to be able to read it and use it. That job is handled by ASP.NET personalization providers.
In Tutorial 11 on databinding, we saw that .NET includes a new provider pattern. Providers hide the coding differences involved in creating the necessary objects for connecting to various databases. Just pick a provider (for example, SQL Server or Access), and the provider does the dirty work of manufacturing connections and such. ASP.NET includes two personalization providers out of the box: a profile provider for custom user data and a personalization provider for Web Parts as we saw in Tutorial 7.
ASP.NET defines the fundamental provider capabilities in an abstract class named PersonalizationProvider. Those capabilities include such things as loading and saving personalization properties and managing their relationship to any Web Parts used within a site. ASP.NET provides a default implementation of these capabilities in a concrete class named SqlPersonalizationProvider, which is derived from PersonalizationProvider.