2

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.

Community
  • 1
  • 1
DrGriff
  • 4,394
  • 9
  • 43
  • 92
  • 2
    even in classic ASP.NET you should not paste all this garbage to each roundtrip - this is what the session-variables are good for. If you don't like this just use any other data-caching-strategy on the server-side. – Random Dev Feb 28 '12 at 10:54

2 Answers2

4

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.

Jamiec
  • 133,658
  • 13
  • 134
  • 193
  • MS Server AppFabric has a cache that I'm using for just this use case. – linkerro Feb 28 '12 at 11:28
  • @linkerro - Thats what I had in my head, but for some reason typed "Azure". Did the name change somewhere? – Jamiec Feb 28 '12 at 11:31
  • @Jamiec - The Azure and Server products are different. The current versions don't have feature parity, but Microsoft has stated that they will converge in the future. Azure AppFabric runs on Windows Azure only, and Server AppFabric is intended for the private cloud/server farm. – linkerro Feb 28 '12 at 11:34
3

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.

Nick Ryan
  • 2,662
  • 1
  • 17
  • 24