[Download Sample Project]
Why is the Profile class (formerly called Personalization) one of the most interesting new features of ASP.NET Version 2.0? Unlike membership, roles, and other personalization-related areas, it has much potential for general increase in state capability that is more efficient than we have had before in the inherently stateless web application.
Generally it is accepted good architectural advice to keep your application as stateless as possible to make it easy to scale. Yet state is what mainly differentiates web development from desktop development in capability, so it could potentially be very important to all aspects of web development. The Session object has been so valuable, and Profile has the potential to be an object that works alongside session to improve a web application's control of state.
Why not just create a session with a two-year timeout? The session is very important for authentication and authorization. Running out to lunch and leaving your browser open could cause a compromise of all the company's passwords or other damage. So wouldn't it be nice if session could be used for that security purpose and if we had a strongly-typed object, which is efficient in memory and has an infinite timeout that developers can control?
This is a simple description of the Profile object. Now, because the Profile object is strongly typed, at runtime we cannot add properties as we could with Session. There is no dynamic runtime change of structure with this Profile object. Planning ahead is the way to go here.
Also, Profile is more intelligent and efficient in the way it stores and reads data. Session always loads the whole session dictionary when you only want to query one value. Profile only looks up data when it is used.
Why do I call it an object instead of a class? Like the Session object, the Profile object is readily available to our web forms. As the session object is held in the HttpContext.Current.Session property, the Profile object is held in the HttpContext.Current.Profile property. This means if you are not in a Page-derived class, then import System.Web.HttpContext, and use Current.Profile to access its properties.
So setting and reading a Profile property from a page object method is as simple as:
Profile.Name = "MyName"
Dim MyName as String = Profile.Name
And if you are not in a Page-derived class but in a custom class method:
Current.Profile.Name = "MyName"
Dim MyName as String = Current.Profile.Name
Comparing Profile and Session:
1) Both objects store separate data for each user of your web application without the developer having to worry about coding for such.
2) Session often needs a small timeout value to protect the user enough, while Profile only ends at the developer's discretion.
3) Profile allows control over clearing by inactive profiles versus active ones, time periods, etc., while session is one or all.
4) Profile is strongly typed and Session is not.
5) At runtime, a key can be added to Session, a property for Profile must be designed in before runtime.
6) Session must load the entire dictionary to read only one value, while Profile can read just one property efficiently (more scalable).
7) Both can store any kind of object.
Now Session can focus on authentication authorization concerns, as we have a stronger candidate for state management.