Introduction

In this brief tutorial, we'll look at five different ASP.NET objects we can use to store data. Two of these, the Application and Session objects, should be pretty familiar to anyone coming from ASP. The other three, Context, Cache and ViewState are brand new to ASP.NET. Each object is ideal under certain conditions, varying only in scope (that is the length of time data in them exists, and the visibility of the data), and it's a complete understanding of this variation that we are after. Also, most of these objects have alternatives that we'll briefly look at.

Scope

Since the only difference between all these objects is their scope, it's important to have a clear understanding of exactly what this means. Within the context of this discussion, scope refers to how data inside these objects (or the objects themselves) live for. For example, a user's user ID should exist until he or she logs out, but the new password he or she enters should only exist for the life of the individual request. Scope also refers to the visibility of the data. There're only two types of visibility, data is either available throughout the entire application or for a specific user. An example of this would be the SMTP server name to use when sending an email which should be globally accessible, whereas an email address is specific to an individual user.

Commonality

The above objects all expose their data-storage capabilities via something similar to a HashTable. In other words, getting or setting information into or out of any of them is very similar. All can hold any object as a value, and while some can have an object as a key, some can only have a string - which is what you'll be using 98% of the time. For example:

HTTPApplication

The Application object is an instance of the System.Web.HTTPApplication class. Typically you would set values in the Application object on the Application_Start event of the Global.Asax or the BeginRequest event of a HttpModule. Logical values to store would be the SMTP server to use when sending out emails, the administrator's contact email address, and any other value which you might globally need across all users/requests.

Worker Process Recycling and Web Farms

While it's correct to say that data stored in the Application exists as long as the website is up, it would be incorrect to simply leave it at that. Technically, the data in the Application exists as long as the worker process (the actual aspnet.exe if you will) exists. This can have severe repercussion and isn't a mere technicality. There are a number of reasons why the ASP.NET worker process recycles itself, from touching the web.config, to being idle, or consuming too much RAM. If you use the Application object by setting values to it in the Application_Start event and only read from it in your classes/pages, then no problem. When the worker process recycles itself, Application_Start will fire and your values will be properly set. However, if you set a value in the Application_Start event, update the value later on, when the worker process recycles itself, it'll default back to the Application_Start value.

Something else to keep in mind is that data stored in the Application object is specific to a computer and can't be (easily) shared across web farms.

Alternatives

The Application object might have been quite useful in Classic ASP, but a number of better alternatives (in my opinion) are now available.

Web.Config

If you require values that are readonly/constants (such as our SMTP server example), consider using the web.config. Unlike values in the Application, the web.config can be easily and quickly changed. You can do considerably advanced things in the web.config, check out my tutorial on Creating Custom Configurations.

Constants

You can leverage the Object Oriented nature of ASP.NET and create a utility class with public constants. To be honest, unless you are just mocking something up, I'm not sure why you would ever use this method over using the web.config. It really gives you nothing except for headaches in the long run.

HttpCache + (XML | DB)

While custom sections in the web.config is definitely the way to go for read-only values, what can we do about read/write values and avoid worker process recycling? The answer is to store values in an XML file or database. While you could do the same thing in classic ASP, you can now leverage a new storage object, the HttpCache (which we'll cover next) to avoid any major performance penalty you would otherwise have. This also avoids any web farm issues you'd have with the HttpApplication class.

Conclusion

It is my opinion that the usefulness of the HttpApplication class, from a data storage point of view, is greatly diminished in ASP.NET. Powerful custom configuration sections in the web.config are a far more elegant and flexible solution for read-only values. Using XML files or a database is ideal for read/write values and web farms, and when combined with the HttpCache object leaves poor'ol Application in the dust.

HttpCache

The HttpCache (cache) class is the first new storage class we'll look at. It's also the most unique. There are a couple of reasons for this uniqueness. First, HttpCache isn't really a storage mechanism, it's mostly used as a proxy to a database or file to improve performance. Secondly, while you read values from the cache by specifying a key, you have a lot more control when inserting, such as how long to store the data, triggers to fire when the data is removed, and more. When accessing values from the cache, there's no guarantee that the data will be there (there are a number of reasons why ASP.NET would remove the data), as such, the typical way to use the cache is as follows:

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:

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 "sessions are evil". 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><!--<span class="code-comment"> can use a mode of "Off", "InProc", "StateServer" or "SQLServer".
These are CaSe-SeNsItIvE --></span><sessionStatemode="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" --> "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:

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.

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:

Additionally, you must run a script to create the database. This script is located in system drive\WINNT\Microsoft.NET\Framework\version\InstallSqlState.sql, for example: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\InstallSqlState.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 Localization Tutorial 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:

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:

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

'VB
Dim 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:

'VB
'Fires when the request is first made
Sub Application_BeginRequest(ByVal sender AsObject, ByVal e As EventArgs)
Context.Items.Add("StartTime", DateTime.Now)
EndSub'fires at the end of the request
Sub Application_EndRequest(ByVal sender AsObject, ByVal e As EventArgs)
Dim startTime As DateTime = CDate(Context.Items("StartTime"))
If DateTime.Now.Subtract(startTime).TotalSeconds > 4Then'Log this slow request
EndIfEndSub

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.

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.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Comments and Discussions

Hello All, This article is helpful for .NET web developers. But, I need to point out several things/issues in here just for reminding.

1> Caching technique is cool but it causes many troubles too. At first run all client side data are loaded into the temp memory(RAM) and cached for next run so your browser contents will not be updated with server for 2nd run. That means you will see the same data as before instead of new until you do a "full refresh". Is that confusing? Don't think you can click "Refresh" to update your browser with server. No, it won't work that way. You must do a complete refresh in order to update the old data from server (eg. Ctrl + F5). For people who has no programming background he/she will be always got confused by the caching thing. My suggestion is if you can avoid to use cache then you should avoid it. You have plenty choices to speed up your website for example optimizing the Store Procedures, SQL queries and c# loop statements. You can avoid EVAL() function, not using VB for .NET (C# is faster); not using Flash and big size images.

2> Be ware of the Session state as it has time limit. For example, if an user opened a webpage which contains the session data then he ran away for lunch or did something else. After 25 minutes (which is default time out setting for session) he came back to that page, trying to click on the save button then he would likely get an error message - with a returned null data from SQL DB. The data that saved in session ID were expired for security reason. If he is not a programmer then he might think that the website is down and calls up your company for complaining.

The above scenarios demonstrated a fact - the views between users and the programmers are big different. The solution really depends on client's needs.

hi i am new buddy into asp.net.i had well object oriented experienced in java.But asp.net i could able to achieve it what i did in java.can you suggest me good books to get well understood as.net.Thanks in advanceNakkeeran.k

<1> Java is very similar to C#. As long as you know OOD and java programming you should be fine on c#.net. Do not worry about Asp.net which is just a platform. If you can read through the Matthew MacDonald's asp.net book for beginners then you should not have any problems on .net programming on front-end. After that you can read pro asp.net, pro SQL server, Web service and Ajax.

<2> You should debug/test those sample codes on the textbook. Try to get a small .net project running. On that book, Matthew will guide you through the setup/installation of IIS and the .net platform/server and show you how to setup a simple website and etc....

Hi,I am trying to catch a Session variable in a class using (System.web namespace used IRequireSession,HttpHandler is used)process request(HttpContext Context){ userID=convert.ToInt32(HttpContext.Current.Session["userID"]);}

this Works fine in IE but it does not pass Session in Firefox . it shows null. But instead session if we pass value using request.querystring it works fine in firefox as well. Though i am using quesrystring now,but unable to figure out why in firefox it does not catch the Session.

Thanks for the great article. I'm new to ASP.net but had/have need of caching and the variety that exists on the subject. Your article cleared a lot up. You mention HttpCache above. And in your code you reference it just as cache["var"] = "otherVar". Is the HttpCache you refer to actually HttpRuntime.cache?

Yes. They all point to the same instance of an object...they are just exposed by different classes.In a page you can simply do Cache[...]...because the base Page class exposes a Cache property, but in reality it's the same as HttpRuntime.Cache.

The only condition for getting HttpRuntime.Cache is that you need a reference to System.Web.dll in your project. I'll often add a reference to this even in my business layers just for the cache (it always throws a couple people off, but there's truly no harm in it).

There are products available now, that will do redundant stateservers and loadbalancing, which should be a lot quicker and cheaper than SQL server.I think one of them is called Scaleoutsoftware and the other one is from Alachisoft. Can't remember their names.

In the example above, there's a dummy call to DataBaseProvider.GetStates(). In your code, this would be the method which creates and opens the connection, creates the command object and fills a new DataTable from a dataAdapter. If you could show me what your data access layer looks like, I might be able to help.