Home/ Questions/Q 606685
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T17:16:49+00:00

Let’s say you’re building something simple, like a data entry/CRUD form for working on

  • 0

Let’s say you’re building something simple, like a data entry/CRUD form for working on an entity called Customer. Maybe you pass the CustomerID in via Session state.

I tend to write a lot of fairly boilerplate plumbing code around handling that Session variable in a particular way. The goals vary slightly but tend to be things like:

  • Avoid cluttering the main flow of the page with plumbing code
  • Handle the back button intelligently
  • Remove the variable from Session and persist it to ViewState ASAP
  • Code defensively for failure situations where the state doesn’t get passed, or is lost

Do you have a best practice for handling this situation? Do you have classes in your stack that handle this perfectly every time? Do you just call the Session variables directly? Do you use encrypted QueryString and avoid Session variables in this situation entirely in order to make the back button work a little better?

Lately I’ve been using Properties with Session variables. Here’s a simple example that I just threw together, although please keep in mind that this example would not be very tolerant of the back button:

Private ReadOnly Property CustomerID() As Integer
    Get
        If Me.ViewState(Constants.CustomerID) Is Nothing Then
            If Me.Session(Constants.CustomerID) Is Nothing Then
                Throw New ApplicationException("CustomerID was not persisted.")
            Else
                Me.ViewState(Constants.CustomerID) = Me.Session(Constants.CustomerID)
                Me.Session.Remove(Constants.CustomerID)
            End If
        End If

        Return Me.ViewState(Constants.CustomerID)
    End Get
End Property

So, how does your shop handle this? Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Teams I have worked on do not pass this kind of workflow information around in session, primarily because of the difficulty it poses to web farms/gardens. We think of session as a container for information that is relevant most (if not all) of the time from the moment the user first hits the site to the moment they leave. Even then, I’d only use session if that information was very expensive to retrieve/build, and only if I knew that the load balancer would stick the user to a particular server in a farm or that we had a suitable out-of-process session provider in place.

    Instead I would pass this type of information via the query string, hidden input field, or ViewState (if enabled), and provide friendly error-handling when invalid values are sent. If history management is important, I would leverage ASP.NET AJAX history management.

    • 0