This is only my opinion, as I am sure everyone has their own reasons
for using different methods.
If I am storing a small piece of information, lets say an ID or
something that needs to persist longer than one page request (otherwise
I would use viewstate or query strings) I rather not apply all the
overhead of opening a database connection, storing a value, reading a
value etc..
If i need to store something small, and it can be persisted into
memory, I just use the Session object.
Don't get me wrong, if I am storing a large amount of information, I
will store it to a database, but for small data, a database is a little
overkill IMO.
In addition, the profile tools that are deployed with .NET 2.0 only
have a SqlProvider for the datasource that is packaged. You could write
your own provider for the profile tools, but this just seems like alot
of extra work for nothing if you ask me.
I did attempt to use the Membership/Role tools in .NET 2.0, but IMO the
tables that MS created for these tools are convoluted, difficult to
maintain, come with NO remote management tool (if you are deploying
your website to a webhost) along with a number of other quirks.
I am sure that in future versions these tools will improve, but sadly I
cannot jump on the bandwagon like everyone else, maybe I am just a
little engrained and stubborn in my ways... probably the latter =)
my 2 cents
Sean
