WebParts and the need for a Database

I'm doing some work creating WebPart components in ASP.NET 2.0 and discovered a dependency that I wasn't initially expecting...the need for a database.

It appears that in order to even place a WebPart onto a form, you need to have a database. Or at least a persistent data store. A little bit of investigation found this information available in a number of places. The WebPart isn't actually the problem, so much as the WebPartManager. The manager is responsible for keeping track of the various WebPartZones and which WebPart is in which Zone. To persist this information across iterations of the page, the location information is stored in a database. So, even when the page is displayed the first time, a database connection needs to be available.

While you can create your own provider, the easiest mechanism is to use the aspnetdb, which is also used by the Membership and Role providers. To add the database to an existing SQL Server instance (either SQL Server 2000 or 2005), use the aspnet_regsql command, which is found in c:\Windows\Microsoft.NET\Framework\v2.0.50215. Once the database is available, a connection string (call it AspNetDbConnectionString to match the upcoming example) should be defined in the web.config file, along with a webParts element that includes a personalization tag, similar to the following:

<webParts>
  <personalization defaultProvider="SqlPersonalizationProvider">
    <providers>
      <add name="SqlPersonalizationProvider"
        t
ype="System.Web.UI.WebControls.WebParts.SqlPersonalizationProvider"
        connectionStringName="AspNetDbConnectionString"
        applicationName="/" />
    </providers>
    <authorization>
      <deny users="*" verbs="enterSharedScope" />
      <allow users="*" verbs="modifyState" />
    </authorization>
  </personalization>
</webParts>