Introduce to Data Storage Objects in ASP.NET

First thing we do is declare a cacheKey [line: 2] which we'll use when retrieving and storing information from and into the cache. Next, we use the key and try to get the value from the cache [line: 3]. If this is the first time we called this method, or if the data has been dropped for whatever reason, we'll get null/Nothing [line: 4]. If we do get null/Nothing, we hit the database via the fictional DataBaseProvider.GetStates() call [line: 5] and insert the value into the Cache object with our cacheKey [line: 6]. When inserting, we specify no file dependencies and we want the cache to expire in six hours from now.

The important thing to note about the code above is that the processing-heavy data-access code DataBaseProvider.GetStates() is skipped when we find the data in the cache. In this example, the real storage mechanism is a fictional database; HttpCache simply acts as a proxy. It's more likely that you'll want to retrieve information based on parameters, say all the states/provinces for a specific country, this is easily achieved via the VB.NET code below:

Private Function GetStates(ByVal countryId As Integer) As DataTable
Dim cacheKey As String = "GetStates:" & countryId.ToString()
'the key to get/set our cache'd data
Dim dt As DataTable = CType(Cache(cacheKey), DataTable)
If dt Is Nothing Then

dt = DataBaseProvider.GetStates(countyId)
Cache.Insert(cacheKey, dt, Nothing, _
DateTime.Now.AddHours(6), TimeSpan.Zero)
End If

Return dt
End Function

All I really had to do was add the parameter to my cacheKey, which means if I first try and get the states for country 3, my cacheKey will look like GetStates:3 and I'll need to hit the database. Subsequent requests for GetStates:3 will avoid the DB call. However, when I ask for states of country 2, my cacheKey looks like GetStates:2, which, when first called will hit the DB, and subsequently retrieve the right values.

SessionState

Sessions exist for the lifetime of a specific user's visit, or until the session timeouts, or you remove it. One thing you probably heard a lot in your ASP days was "don't use sessions", or "". The problem with sessions is how easy they were to use combined with their potentially serious impact on performance, since they were stored in memory. In ASP.NET, you have the choice of storing sessions in memory, in a special service that is part of ASP.NET, or in a SQL database. Having this choice, and using it wisely, makes using sessions in ASP.NET a good thing.

You control where sessions are stored via the web.config's sessionState element, specifically the mode attribute:

<system.web>
<!-- can use a mode of "Off", "InProc", "StateServer" or "SQLServer".
These are CaSe-SeNsItIvE --&gt
<sessionState mode="InProc" />
...
</system.web>

InProc

InProc means that sessions are stored inside the ASP.NET worker process - this is pretty much how sessions in classic ASP work. Storing data this way can lead to performance issues (since it's using your web server's RAM), and also has all the issues associated with worker process recycling that plagues read/write usage of the Application object. However, wisely used for the right website, such as keeping track of a user ID in a small/medium sized site, they are extremely performing and an ideal solution. You don't need to do anything special, other than setting the sessionState's mode to "InProc".

StateServer

StateServer is a service which is off by default. You can enable it by going into "Administration" --&gt "Services" and right-clicking on "ASP.NET State Service" (go to Properties and select "automatic" if you want it to start when Windows starts). When your sessionState is in StateServer, sessions aren't stored in the ASP.NET worker-process, which avoids the worker process recycle problem. Additionally, two or more separate web servers can access a single StateServer, meaning session state will automatically be shared across a web farm.

There are two very important things to keep in mind when using StateServer. Firstly, it isn't as fast as having the data stored directly in the ASP.NET worker process. This can be easily resolved by smarty using the HttpCache class. Secondly, data stored in the StateServer must be serializable. Strings, ints and most built-in types are mostly all automatically serializable. Custom classes can typically be marked by the System.SerializableAttribute attribute:

[Serializable()]
public class User {
   private int userId;
   private string userName;
   private UserStatus status;

   public int UserId {get { return userId; } set { userId = value; }}
   public string UserName {get { return userName; }set { userName = value; }}
   public UserStatus Status {get { return status; }set { status = value; }}

   public enum UserStatus {
      Invalid = 0,
      Valid = 1
   }
}

To use StateServer, you must specify both the SessionState mode, as well as the address of the StateServer via stateConnectionString. StateServer runs on port 42424 by default, so the example below connects to the state server on the local machine.

<sessionState mode="StateServer" 
       stateConnectionString="tcpip=127.0.0.1:42424" />

SQL Server

Using SQL Server is much like using StateServer. Both require data to be serializable, both are overall slower (but won't cause the entire app to have performance issues), and both can be accessed by multiple web servers. The difference between the two is, well obviously, one uses the StateServer service while the other uses SQL Server. This has pretty wide implications. By storing your sessions in SQL Server, you can take advantage of multiple databases, load balancing, and fault-tolerance. You also have to pay big money for it.

Enabling SQL Server is much like StateServer: set the mode to SQLServer and specify the connection via the sqlConnectionString attribute:

<sessionState mode="SQLServer" 
   stateConnectionString="Initial Catalog=Session;server=localhsot;uid=sa;pwd=;" />

Additionally, you must run a script to create the database. This script is located in system driveWINNTMicrosoft.NETFrameworkversionInstallSqlState.sql, for example: C:WINDOWSMicrosoft.NETFrameworkv1.1.4322InstallSqlState.sql on my computer (Windows instead of WinNT because I'm using XP). Simply run it, and you're ready to go.

Alternatives

Considering how flexible and powerful sessions are now implemented, there aren't any great alternatives, but here's a list anyways:

Cookies

Cookies behave pretty much the same as sessions, but are stored on the user's computer. This makes them horrible for large data or sensitive information. Additionally, not everyone has cookies enabled (truer and truer with increased privacy concerns). On the flip side, unlike sessions, you can easily use cookies to store information across multiple visits. Cookies used to be a great place to store information you didn't really care if it was kept or not, like a username (hey, if it's there great, the user has one less thing to type. If not, oh well), but most browsers do a better job of this than you can with cookies.

Querystring

The querystring used to be considered a possible alternative to sessions. But again, you can't store large/complex data in them or sensitive information. Additionally, it's a real maintenance nightmare.

URL Rewriting

I won't go into details about URL Rewriting (check out my where I explain it briefly). I like using URL Rewriting for simple things such as localization because it needs far less maintenance than using the Querystring, and looks really professional. But just like the cookie or querystring alternative, this won't cut it most of the time.

Conclusion

As you can probably tell, sessions in ASP.NET are a lot more useful than they were in classic ASP. The main reason being that you have a good alternative to storing them in memory. But with that comes a bunch of other alternatives: sharing them across web farms (state server/ SQL Server), load balancing (SQL Server), fault tolerance (SQL Server), and a couple of other nice things. Another great feature of sessions in ASP.NET is that they'll work even if the user's browser doesn't support session cookies. This is done by automatically placing the session ID in the querystring, instead of a session cookie. Sure, I just said the QueryString was a bad alternative, but this is automatically done, maintenance free for us!

ViewState

You've probably heard a lot about viewstate and ASP.NET. It's one of the many big-things in ASP.NET. Thankfully (or not depending on how you look at it), I don't plan on going into any details about it, aside for how you can use it as a storage mechanism. For all its glory, the ViewState is a hidden form field. You probably used hidden form fields frequently in classic ASP to track a value between one page and the posted-to page...our usage of the ViewState is no different. Its scope, as you can probably imagine, is for a single user, from one page to another.

What some people don't realize about the viewstate is that it isn't some mystical thing that they aren't allowed to touch. You can easily store and retrieve values from and into it:

'VBDim pollId As Integer

If Not Page.IsPostBack Then
pollId = getPollId()
viewstate.Add("pollId", pollId)
Else
pollId = CInt(viewstate("pollId"))
End If

In the above example, we call an expensive function called getPollId() [line: 4] and store the result in the ViewState. When the page does a postback, we can avoid that same call and simply retrieve the value from the ViewState.

Conclusion

When it comes down to doing similar things to the above example, using the viewstate is a great solution. You could always simply use a hidden form field, or the Page.RegisterHiddenField() which creates a hidden field for you, and use Request.Form, but I wouldn't call those alternatives since they are pretty much the exact same. Of course, if you need to store objects, large data, or sensitive information, sessions might be what you want.

HttpContext

Personally, I think I've kept the best for last. I think the HttpContext is probably the least well known of the ASP.NET data storage objects, and while it won't solve all your problems, it's definitely useful in a number of instances. Of all the objects, it has the most limited scope - it exists for the lifetime of a single request (remember the viewstate exists for the life time of two requests, the original one and the postback). The most common use of HTTPContext is to store data into it on Application_BeginRequest, and access it as need be throughout your page, user controls, server controls and business logic. For example, say I built a portal infrastructure which, at the start of each request, created a portal object which identified which portal the request was in and which section within the portal. We'll skip all the portal code, but your Application_BeginRequest would probably look something like this:

protected void Application_BeginRequest(Object sender, EventArgs e) {
Context.Items.Add("portal", new Portal(Request.Url));
}

You can then access the instance of the portal throughout the request via:

'VBDim portal As Portal= CType(Context.Items("portal"), Portal)

You shouldn't use HttpContext to pass information between a Page and UserControls, instead use strongly-typed controls, interfaces and base classes. You should use HttpContext to store request-specific information that you want to make accessible throughout all layers of your application.

Another example of using the HttpContext is for a simple performance monitor:

When the application starts, we store the current time in the context [line: 4]. When the application ends, we retrieve that value [line: 9], compare it to the current time [line: 10], and if it's greater than a certain threshold (4 seconds in this case), we could log some information which might help us identify bottlenecks.

Conclusion

There are two reasons I like HttpContext so much. Firstly, because I find it relatively unknown and unused. Even Microsoft's documentation doesn't do justice to how useful it can be. Secondly, because it's just really useful and handy to have. There are alternatives to using it, the Session is probably the most obvious. If you find yourself unsure of which to use, ask yourself if the information is specific to a user (Session) or specific to a request (HttpContext).

Going the extra mile by strongly-typing

If there's one thing I dislike about all the above mechanisms, it is that they return objects. At worst, this can lead to run-time errors; at best, it'll give you maintenance problems. The solution is strong-type the object. Look at the code below:

So, what's wrong with the above? First of all, we need to cast the Session object to CurrentUser, we need to specify the key "currentUser", and we need to add error handling. The problem is we need to do this every time we access the value. We might do it once in our Page, once in each of our UserControls, and once in some business logic. That's not very encapsulated, is it? Even changing the key from "currentUser" to "User" would require a potentially dangerous search and replace.

The solution is to wrap this code into a Shared/static property:

Public Shared ReadOnly Property CurrentUser() As User
   Get
      Dim _currentUser As User = _
          CType(HttpContext.Current.Session("CurrentUser"), User)
      If _currentUser Is Nothing Then
         _currentUser = New User
         HttpContext.Current.Session.Add("CurrentUser", _currentUser)
      End If
      Return _currentUser
   End Get
End Property

I'll explain the whole HttpContext.Current thing in the next section, for now, just assume that it isn't there. The code hasn't changed much. Basically, we've added some error handling...but this code is encapsulated, look at how much cleaner accessing the value is:

Dim currentUser as User = User.CurrentUser

There's only one hard coded "currentUser" key, and that's in the User class. We aren't having to cast anymore and we have full intellisense support.

Strongly-typing only really makes sense for objects that have a wide scope. The above example is a really good one. But if you find yourself frequently accessing values from one of the above storage objects and repeatedly casting it and doing error checking, consider the above solution.

Accessing these objects from the business layer

All of the above objects are readily available to you when programming in code-behind files. You can simply type "ViewState.Add("xxx", "yyy")", and it works. But really, that works because those are properties of the Page class (go ahead and type Page.V, you'll see the intellisense will list ViewState).

Not all your code will be written in code-behind. You'll likely have a bunch of classes (users, groups, portals, sections, roles...), validation objects, and utility classes which don't inherit from System.web.UI.Page. Does that mean all those objects are lost to you? Not all all. Within a web request, all of those objects are available via System.Web.HttpContext.Current. The above example shows how you can use it. Just remember that HttpContext.Current can return null if your code isn't being executed from within a web request.

It's possible to access the HttpCache object via either the above mentioned method or HttpRuntime.Cache - enabling you to utilize the power of HTTPCache in non-web requests.

Conclusion

Hopefully, this tutorial has given you both an overview of these storage objects, as well as some insight to help you chose the right one for the job. It's important to note that we only looked at the storage capabilities of these objects, some of them actually do a lot more (ViewState and HttpContext). However, you can use their storage capabilities without knowing anything more about them. Always ask yourself how the data will be used. Is it specific for all users (Application, HttpCache), or a specific user (Session, ViewState, Context)? Does it have a long life-time (Application, HttpCache, Session) or a short one (ViewState, Context)?

Remember to consider alternatives, specifically when looking at the Application object. There are some cases where a particular alternative might be the best tool for the job, even if overall it isn't a great thing to use. And make your life easier, and encapsulate access to these storage objects when it makes sense to do so.