Programming Microsoft ASP.NET 4 - Dino Esposito [152]
Page Personalization
ASP.NET pages do not necessarily require a rich set of personalization features. However, if you can build an effective personalization layer into your Web application, final pages will be friendlier, more functional, and more appealing to use. For some applications (such as portals and shopping centers), though, personalization is crucial. For others, it is mostly a way to improve visual appearance. In ASP.NET, personalization is offered through the user profile API.
ASP.NET personalization is designed for persistent storage of structured data using a friendly and type-safe API. Loading and saving personalized data is completely transparent to end users and doesn’t even require the page author to know much about the internal plumbing.
Creating the User Profile
A user profile is a plain .NET class that exposes a bunch of properties. The class can be defined in two possible ways depending on the model of Web application you are building within Visual Studio.
If your project is a Web site project, you define the user profile model declaratively through attributes in the web.config file. At run time, the ASP.NET build machinery will group these properties into a dynamically generated class. When the application runs and a page is displayed, ASP.NET dynamically creates a profile object that contains, properly typed, the properties you have defined in the data model. The object is then added to the current HttpContext object and is available to pages through the Profile property.
For a Web Application Project (WAP), instead, a bit more work is required on your part, and type-safety comes at the cost of writing the user profile class manually. You don’t use the Profile property directly from the HttpContext object but, at the end of the day, the work being done underneath is not different. The only difference is in who actually writes the code—you in a WAP scenario, or the ASP.NET runtime in a Web site project.
Any profile data is persisted on a per-user basis and is permanently stored until someone with administrative privileges deletes it. The data storage is far away from the user and, to some extent, also hidden from the programmers. The user doesn’t need to know how and where the data is stored; the programmer simply needs to indicate what type of profile provider she wants to use. The profile provider determines the database to use—typically, a Microsoft SQL Server database, but custom providers and custom data storage models can also be used.
Note
In ASP.NET, the default profile provider is based on SQL Express, a lightweight version of SQL Server. The default physical storage medium is a local file named aspnetdb.mdf, which is commonly located in the App_Data folder of the Web application. You can rename and move the file as you wish. If you change its schema, though, you have to employ an ad hoc provider that understands the new schema. Because it is an MDF file, you can also host the database in a full edition of SQL Server on the host machine.
Definition of the Data Model in a Web Site Project
Let’s begin our exploration of the profile API focusing on the tasks required in a Web site project. The profile API was originally introduced in ASP.NET 2.0 along with the Web site model at a time in which the popularity of the WAP model was in a downturn and everybody seemed to want to get rid of it. That sentiment was only a flash in the pan, however. The WAP model soon regained its prominent position in the minds of developers, and today Visual Studio 2010 offers two models to choose from. The choice is not painless when it comes to the profile API. I’ll present the profile API from the perspective of a Web site application first—because it’s likely you might have heard of it already. Next, I’ll point out differences related to WAP projects.
To use the ASP.NET profile API, you first decide on the structure of