• Choose a category
• All
• Classic-Fiction

type="System.Web.Profile.SqlProfileProvider" />

The nodes within the section list all the currently registered providers. The previous code is an excerpt from the machine.config file. Attributes such as name and type are common to all types of providers. Other properties are part of the provider’s specific configuration mechanism. Tightly connected with this custom interface is the set of extra properties—in this case, connectionStringName and description. The description attribute is simply text that describes what the provider does.

The connectionStringName attribute defines the information needed to set up a connection with the underlying database engine of choice. However, instead of being a plain connection string, the attribute contains the name of a previously registered connection string. For example, LocalSqlServer is certainly not the connection string to use for a local or remote connection to an instance of SQL Server. Instead, it is the name of an entry in the new section of the configuration file. That entry contains any concrete information needed to connect to the database.

The LocalSqlServer connection string placeholder is defined in machine.config as follows:

connectionString="data source=.\SQLEXPRESS;

Integrated Security=SSPI;

AttachDBFilename=|DataDirectory|aspnetdb.mdf;

User Instance=true"

providerName="System.Data.SqlClient" />

As you can see, the connection string refers to an instance of SQL Server named SQLEXPRESS and attaches to the aspnetdb.mdf database located in the application’s data directory—the App_Data folder.

Structure of AspNetDb.mdf

As a developer, you don’t need to know much about the layout of the table and the logic that governs it; instead, you’re responsible for ensuring that any needed infrastructure is created. To do so, you use the Build|ASP.NET Configuration menu item in Visual Studio to start the ASP.NET site administration tool. A view of the tables in the database is shown in Figure 7-8.

Figure 7-8. A view of the interior of the AspNetDb database and the profile table.

Note that the AspNetDb database isn’t specific to the personalization infrastructure. As you can see in the figure, it groups all provider-related tables, including those for membership, roles, and users. The internal structure of each database is specific to the mission of the underlying provider.

Custom Profile Providers

The SQL Server profile provider is good at building new applications and is useful for profile data that is inherently tabular. In many cases, though, you won’t start an ASP.NET application from scratch, but you will instead migrate an existing application. You often already have data to integrate with the ASP.NET profile layer. If this data doesn’t get along with the relational model, or if it is already stored in a storage medium other than SQL Server, you can write a custom profile provider. An old but still helpful link is the following: http://msdn.microsoft.com/msdnmag/issues/07/03/ASPNET2/default.aspx.

Profile providers push the idea that existing data stores can be integrated with the personalization engine using a thin layer of code. This layer of code abstracts the physical characteristics of the data store and exposes its content through a common set of methods and properties. A custom personalization provider is a class that inherits ProfileProvider.

Finally, note that a custom provider doesn’t necessarily have to be bound to all profile properties. You can also use the default provider for some properties and a custom provider for others. Here’s how you specify the provider for a property using the declarative approach:

...

In the preceding code, the BackColor property is read and written through the MyProvider provider. If you are in WAP, instead, and wrote your profile wrapper class, you resort to the ProfileProvider