Updating GridView after insert

2
votes

We are using Visual Studio 2010 and .NET 4.0 for an ASP.NET website and MVC for the general architecture.

There are 2 parts to this question. Nothing is on how to do this but what is the right way as per good design and industry standards.

  1. If I have a GridView (AJAX enabled) with 1000 + records (lot of data), and show 100 records at a time, do I go back to database for next 100 records, or store the data in session and just rebind the gridview by taking new data from session?

  2. In the case of an insert, I have 2 choices. One, insert a record in the database and reload the gridview and rebind. Two, insert record in session and database and update the GridView based on session data. I need not download new data from database.

Can you please point me in right direction?

3
c#asp.netgridview

3 Answers

3
votes

Forget the 1000 records at a time... If you're only showing 100 at a time, that's all you need to worry about. In my opinion, requery the database. 100 records at a time isn't much. Don't rely on session for this sort of thing, embrace the 'stateless' nature of the web.

I don't think using session gives you much benefit. Either way, the info needs to be sent to the user's browser. Querying the database for 100 records is probably a trivial operation (in terms of latency). From a development standpoint, the added complexity of introducing session state here isn't worth it. (Ask yourself, exactly what benefit does session give you here?)

That's just my opinion, others may differ. But I can't imagine running into too many problems querying for 100 records at a time in this scenario

1
votes

You can store the data in the cache object at the server to avoid having to read the database each time. http://msdn.microsoft.com/en-us/library/aa478965.aspx

1
votes

Read this article from ScottGu. Page your recordsets at the database. In most cases this is the correct approach. The article shows some benchmarks. If your site becomes high traffic, storing in session can be resource intensive. If you were to scale to a webfarm, you'd likely end up storing session state in sql server anyway.

Session data is also volatile. What if the user opens the same page in 2 browser windows? You'll end up stepping on the toes of each page. What if the user walks away from the page, letting session or cache expire? You'll have the same issues with Cache.

Paging at the server scales the best.

http://www.4guysfromrolla.com/articles/031506-1.aspx#postadlink