Profile Vs Session

First, everything in session is serialized on every request. On the other hand, accessing a member of the profile is serialized per request of each item. As more information is collected about a user to provide a richer UI there is an awful lot of information being serialized every request that realistically isn't needed. Enter the profile and its lesser recognized ability to define more than simple value types as members. Let’s say we have an operation that needs to be stored in a user’s profile, and its information can be represented as a large logical object graph. Instead of storing this information in session, we define a struct for the object graph. When we need the information, we retrieve a copy from profile, perform our business operation, set the updated information on the profile, and move on to the next part of the site. This is going to take some a bit of planning and puts the earnest on architects to logically group items in the profile, but the end result can dramatically improve performance by minimizing the information serialized on every request to only that needed by the majority of the site.

Unlike session state, the profile properties feature requires a considerable amount of configuration to use. To use profile properties, you must not only configure a profile provider, but you must pre-configure all of the profile properties that you want to store.

msdn2.microsoft.com/en-u...ry/z1hkazw7.aspx

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.


so i guess Profile might be a better choice, just because it would mean less network traffic with less work on my behalf. with sessions, i'd have to write custom code if i didn't want the whole blob to be transferred between client & server on every request. with Profiles, i can just add a few simple lines to configure my own Profile Provider and then depending on what property i get/set, only that property is transferred. quite handy.

the fact that i have to have all the profile variables defined compile-time doesn't really worry me much.