Up to now you examined the many techniques which allow you to remember the little level of the user and level of the application of the data. However, these techniques suffer from one major
limitation: they exist only as long as the user is in session and the
web application is running! However, many web sites require the ability
to persist user information across sessions. For example, perhaps you
need to give users the ability to build an account on your site. Maybe
you need to persist instances of a ShoppingCart class across sessions (for an online shopping site). Or perhaps you wish to persist basic user preferences (themes, etc.).
While you most certainly could build a custom
database (with several stored procedures) to hold such information, you
would then need to build a custom code library to interact with these
database objects. This is not necessarily a complex task, but the
bottom line is that you are the individual in charge of building this sort of infrastructure.
To help simplify matters, ASP.NET ships with an
out-of-the-box user profile management API and database system for this
very purpose. In addition to providing the necessary infrastructure,
the Profile API allows you to define the data to be persisted directly
within your Web.config file (for purposes of simplification); however, you are also able to persist any [Serializable] type. Before we get too far ahead of ourselves, let's check out where the Profile API will be storing the specified data.
1. The ASPNETDB.mdf Database
Every ASP.NET web site built with Visual Studio 2010
can support an App_Data subdirectory. By default, the Profile API (as
well as other services, such as the ASP.NET role membership API, which
is not examined in this text) is configured to make use of a local SQL
Server 2010 database named ASPNETDB.mdf, located within the App_Data folder. This default behavior is due to settings within the machine.config
file for the current .NET installation on your machine. In fact, when
your code base makes use of any ASP.NET service requiring the App_Data
folder, the ASPNETDB.mdf data file will be automatically created on the fly if a copy does not currently exist.
If you'd rather have the ASP.NET runtime communicate with an ASPNETDB.mdf
file located on another networked machine, or you'd prefer to install
this database on an instance of SQL Server 7.0 (or higher), you will
need to manually build ASPNETDB.mdf using the aspnet_regsql.exe command-line utility. Like any good command-line tool, aspnet_regsql.exe provides numerous options; however, if you run the tool with no arguments, like so:
you will launch a GUI-based wizard that will walk you through the process of creating and installing ASPNETDB.mdf on your machine (and version of SQL Server) of choice.
Now, assuming your site is not using a local copy of the database under the App_Data folder, the final step is to update your Web.config file to point to the unique location of your ASPNETDB.mdf. Assume you have installed ASPNETDB.mdf on a machine named ProductionServer. The following (partial) machine.config
file would instruct the Profile API where to find the necessary
database items in their default location (you could add a custom Web.config to change these defaults):
connectionString ="Data Source=ProductionServer;Integrated
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Like most *.config files, this looks much worse than it is. Basically we are defining a <connectionString>
element with the necessary data, followed by a named instance of the
SqlProfileProvider (this is the default provider used regardless of
physical location of the ASPNETDB.mdf).
For simplicity, I will assume that you'll use the autogenerated ASPNETDB.mdf database located under your web application's App_Data subdirectory.