In a previous section, we discussed the Profile provider and stated all of its properties and methods that are implemented and accessed by the Profile object and Profile Manager class.
In developing a custom Profile provider, you will need to implement the same methods and properties according to your data store used and the specific schema you have in your database design.
The default Profile provider that ships with ASP.NET 2.0 inherits from ProfileProvider base class. If we want to create a custom Profile provider we have to inherit from either the ProfileProvider or the AspNetSqlProfileProvider. If we want to have our Profile provider interact with a database different from SQL Server 2000/2005, then the ProfileProvider is the best choice. On the other hand, if the data store used is SQL Server 2000/2005 and what we want is just add some properties or methods to the existing Profile provider, then the latter is the best choice.
The ProfileProvider base class has the following structure shown in Listing 3 below:
Listing 3. ProfileProvider Basic Structure
public abstract class ProfileProvider : SettingsProvider
{
public abstract int DeleteProfiles(ProfileInfoCollection profiles);
public abstract int DeleteProfiles(string[] usernames);
public abstract int DeleteInactiveProfiles(
ProfileAuthenticationOption authenticationOption,
DateTime userInactiveSinceDate);
public abstract int GetNumberOfInactiveProfiles(
ProfileAuthenticationOption authenticationOption,
DateTime userInactiveSinceDate);
public abstract ProfileInfoCollection GetAllProfiles(
ProfileAuthenticationOption authenticationOption, int pageIndex,
int pageSize, out int totalRecords);
public abstract ProfileInfoCollection GetAllInactiveProfiles(
ProfileAuthenticationOption authenticationOption,
DateTime userInactiveSinceDate, int pageIndex,
int pageSize, out int totalRecords);
public abstract ProfileInfoCollection FindProfilesByUserName(
ProfileAuthenticationOption authenticationOption, string usernameToMatch,
int pageIndex, int pageSize, out int totalRecords);
public abstract ProfileInfoCollection FindInactiveProfilesByUserName(
ProfileAuthenticationOption authenticationOption, string usernameToMatch,
DateTime userInactiveSinceDate, int pageIndex,
int pageSize, out int totalRecords);
}
In the above listing, the ProfileProvider seems to inherit from the SettingsProvider. In addition to the methods inherited from the ProfileProvider, the custom Profile provider developer should also implement two other methods inherited from the SettingsProvider, which are the SetPropertyValues and GetPropertyValue. The structure of the SettingsProvider is shown below in Listing 4.
Listing 4. SettingsProvider Basic Structure
public abstract class SettingsProvider : ProviderBase
{
// Properties
public abstract string ApplicationName { get; set; }
// Methods
public abstract SettingsPropertyValueCollection GetPropertyValues(
SettingsContext context, SettingsPropertyCollection properties);
public abstract void SetPropertyValues(SettingsContext context,
SettingsPropertyValueCollection properties);
}
As shown in the listing above, the two methods should be implemented by any custom Profile provider. In addition, if the Web application is scoped to interact with a set of Web applications, then the property called ApplicationName should also be implemented. If you are interested in how to implement such a custom profile, visit this online article: Profile Providers
