Any Reason to Use Session Object?

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

I was just wondering if anyone had any good reasons to use the Session
object when the newer Profile object is now available.

Thanks.
 
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
 
If you have a non-SQL based database system that requires special, i.e.,
non-ODBC or ADO.NET interfaces, wrapping that interface into a class that
you can then instantiate and store in the session object allows your
database interface to maintain its state.

Mike Ober.
 
Back
Top