CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-3
DrGriff
DrGriff

Reputation: 4906

ASP.NET MVC - what's the equivalent of ViewState

I have an existing web-forms website that runs on a web-farm (multiple web servers, each request is NON-sticky).

One of the tasks is to retrieve a lot of data from a 3rd party webservice. This is an expensive process (in terms of time taken to respond). The optimal solution has been to initially grab all the data and stick it in the page's ViewState (as a List<Product>. We then have a grid that allows us to page through this list of products. For each request for the next page we don't have to re-visit the slow web service because we've already cached the data in the ViewState.

So, how would I accomplish this using MVC? If I were using classic ASP, I would serialize the list and hold it in a hidden field in the form.

But what is the preferred approach when using MVC? As mentioned, I'm using non-sticky sessions so can't rely upon caching on the server.

If I am to hold it in a hidden-field, then is it sensible to compress the data first (zip) to reduce the size of the page? Again, what's "best practice" here?

Many thanks for any/all advice

Griff

PS - I know there are similar posts out there (e.g. ASP.NET MVC and ViewState), but they don't quite provide the detail I require.

Upvotes: 2

Views: 4249

Answers (2)

Jamiec
Jamiec

Reputation: 136074

Caching, in my humble opinion, is the best way to deal with this; hit the webservice, cache the data, and use that for each subsequent request.

It is possible to share a cache across many web servers. The default behaviour is to hold it InProcess, but this is by no means fixed and can be configured to store it in a remote InProc cache, a database, or any other method of semi-persistant storage. AzureAppFabric caching comes to mind.

Second to that, as you mentioned is to dump all the data in a hidden field, but I dont like this idea for a number of reasons

  • Page bloat - you're submitting this data every time the page is changed
  • Lost data - you must submit a form for every navigation, forgetting to do this means loosing your data

To name 2.

Upvotes: 4

Nick Ryan
Nick Ryan

Reputation: 2670

Your strategy should depend on how volatile the data retrieved from the 3rd party service is going to be and how expensive it is to call it.

  • Volatile and expensive. I would go down the road of caching the data in a distributed cache such as Appfabric Velocity, or Memcached.
  • Non-Volatile and expensive. Cache a copy of it in memory on each server node.
  • Cheap. Hit the call every time you need it. Don't bother caching.

If the data set returned from the service is large, I would not pass this up and down every time you page through your grid data. Only retrieve the data for the current page and render it in your grid. Telerik have a good implementation for this or you could try and roll your own.

Upvotes: 3

Related Questions