We are using Azure for deploying our ASP.NET MVC Web application. As you know, Azure behaves like a web farm. It hosts multiple instances of the same application in multiple VMs. The advantage of this approach is that the number of instances can be scaled up or scaled down according to the load.

For a web developer working with Azure, there are some implications on how you store transient data. If you are using SessionState for storing data, then the Session should be based on a SQL Azure database. SQL Azure database is an expensive option to store session data. It is preferred only if the web application is already using SQL Azure.

For caching, the recommended way to store data is Azure AppFabric Caching. This also has an additional cost. Caching is required only if you are connecting to non-Azure environments using Web Services.

For my Azure web application, we need to store a small amount of data. We are not using SQL Azure. We do not have any external dependence. So we are not using Azure AppFabric Caching.

For storing small bits of data, ASP.NET MVC offers TempData. TempData retains the data between two requests or postbacks. For our application, we need to store the Search Criteria in TempData.

The drawback of using TempData is that it uses the SessionState for storing data. In Azure, where the request can be redirected to any instance, TempData will not work. Fortunately, MVC has extensibility mechanisms which can replace the TempDataProvider. We can write our own TempDataProvider which can store data in custom storage.

In Azure, a custom TempDataProvider can save data in SQL Azure DB, AppFabric Caching, Tables and Blobs, or any third-party caching system like Velocity.

Since, I wanted to store very small bits of data, and I do not want to incur any additional costs, I decided to store the TempData in cookies. So, I wrote a custom TempDataProvider that stores data in cookies and retrieves data back from cookies. Slightly fishy, but it works.

Writing a TempDataProvider means inheriting the ITempDataProvider interface and implementing the two methods – LoadTempData and SaveTempData. Here is the implementation for SaveTempData:

In the above code, I create a new cookie or use the existing cookie from the response object. Since cookies store only string data, I have used the BinaryFormatter for serializing the object into a string. The string is written as a cookie in the user’s browser system.

The other method that needs to be implemented is LoadTempData. The code for LoadTempData method is shown below:

LoadTempData does the reverse of SaveTempData. It gets the request object. Within the request object, the appropriate cookie is retrieved. From the cookie, the string is deserialized back to a binary object. The binary object is stored into a dictionary.

The whole purpose of our custom TempDataProvider is load and save this dictionary in an appropriate location in Cookies.

The code listing for the CookieTempDataProvider class is shown below for completeness:

The article suggests how to add a TempDataProvider to the controller. Create a Base controller for all controllers and initialize as follows:

Hopefully, this simple example helped increase your knowledge of TempDataProviders.

Custom TempDataProvider for Azure
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *