An Approach to Session Usage
by Allan Sieker
The Overview
“We do not pretend to have achieved perfection — but we do have a system — and it works.” – Klaatu
When developing ASP.NET web applications a very common approach to maintaining state is to store variables into the Session.
Session is just one way to store data. Here are some other ones that I know of. Can you think of any others?
• Application (global) – uses server memory.
• Session (user) – can use user memory and/or database storage.
• Data cache (global, but can be user specific with proper handling) – uses server memory.
• Viewstate (web page) – rides along with the page. No server memory.
• Database (global and user) – includes SQL, XML, local files, etc.
• Cookie (user) – stored on the client’s computer and accessed via the browser.
• Query String (user) – doesn’t use server memory – just a lot of developer patience.
• Form fields (web page) – popular in HTML and classic ASP development.
Read the rest of this entry »
WebApp Vs. Website
The bottom line much of the time, is that developers are creatures of habit… much of what we do, we do because that is what we do, and we have no better reason than that. Perhaps the first time we do something we thought it through, but rarely do we go back and revise those thoughts, and conciously choose a different direction, ideology or methodology… for me this is the case with my choice of choosing Website over WebApp for my development.
Recently I began a new project with a co-worker, and although we discussed every aspect of the project, the coding, the tools, the flow, basically every detail as to what was ahead of us, we never addressed whether this would be a WebApp or a Website project. As I began coding my first page of this project, the dev environment was different, my options had changed, and I knew we had not addressed a fundamental decision that we should have addressed.
Read the rest of this entry »
VisualSVN and our .NET Development Environment
Recently our organization (The Net Impact) made the decision to rebuild our entire development environment. As most know this can be both a daunting and yet exciting venture. During the planning phase we had numerous discussions concerning which source control utility to implement and we finally decided to test Subversion versus Microsoft Team Server.
One of the complaints I have had in the past with Subversion is how clunky interfacing with it has been. I feel that in this day and age any command line interface is past its prime, and having to run external third party interfaces is simply annoying. I wanted something fully integrated into our development tools mimicking the functionality of eclipse and PVCS I had used years back.
Read the rest of this entry »