This post originated from an RSS feed registered with .NET Buzz by Peter van Ooijen. Original Post: Where to get your grid's data on the next roundtrip Feed Title: Peter's Gekko Feed URL: /error.htm?aspxerrorpath=/blogs/peter.van.ooijen/rss.aspx Feed Description: My weblog cotains tips tricks and opinions on ASP.NET, tablet PC's and tech in general. Latest .NET Buzz Posts Latest .NET Buzz Posts by Peter van Ooijen Latest Posts From Peter's Gekko

 In a recent post I wrote some things on a datagrid and what to do over roundtrips. In a comment  John asked me what I did with the data over the roundtrips. He mentions 4 ways to store it. I always use the first one: a full reread from the DB on every roundtrip.

This is my situation:

• The data might be changed on the next roundtrip. Actions on the form itself may have caused the changes.
• The bottleneck is the bandwidth. The page's viewstate has to remain as small as possible.

The first point makes a database reread over roundtrips neccesary. In case only the second point applies it would be an alternative to store the data in the cache or session. Still I favor the database. My main reason is that a database server is designed / optimized for caching data and I don't have to reinvent the wheel. To be honest I never measured the difference with using the session or cache object. Given the updates in the DB I need a reread anyway. The apps behave well. The user load is not gigantic but a tiny box can serve all. At this moment I'm working on an application which will be under a greater stress. I hope (trust) the architecture will stand.

My main point is that bandwidth is far more important than server load. It's not a big problem to scale up to a bigger database server or to plug in some Mb's to store the sessions. That's all under your control. Widening the user's bandwith is not.

Having said this, I'm in for any other view. In 2005 it's a delight to see how you can configure caching right on the datasource itself.