Is my gridview paging/sorting inefficient?

I'm using a web service which returns a list of products. I created a Grid View programmatically and used the list as the datasource. However, I can't use the Paging/Sorting methods as it causes errors since I'm not using an ObjectSource control. I handled the paging and sorting manually, but I don't know if I'm doing it efficiently. When the user clicks on a new page, I handle the page index changing like this:

protected void gvProductList_PageIndexChanging(object sender, GridViewPageEventArgs e)
{

    userProducts = Data.GetProductList();

    this.gvProductList.PageIndex = e.NewPageIndex;
    this.gvProductList.DataSource = userProducts;
    gvProductList.DataBind();
}

However, the database is always called when I change pages. Is there a way to make this more efficient, or is that normal for paging? The same goes for sorting, which uses the web service to get the products, then uses a lambda expression to sort the products according to various columns. Each time this happens, the database is called (in order to get the list of products again).开发者_如何学运维 Am I handling this wrongly? I know I can use sessions and such to store the List, but there can be hundreds of custom objects per list and tens of thousands of users at any one time.

I should note that the web service is provided by a third party (and so it's their database being called), which means I won't have access to the SQL Server itself nor any methods to change the web service.

Thanks for any help.

EDIT: I should mention that the product list is the user's shopping cart. Therefore, it's unique per user.

General Consensus: If the shopping cart isn't holding many items, the current method would be okay. However, if caching is required, this can be achieved by either using In Proc sessions, or storing sessions on a SQL Server.

No, it's not efficient since you are bringing back every record in the underlying database (presuming GetProductList() returns all records). The GridView paging just means it only shows the number of rows defined in PageSize for the given PageIndex - but it doesn't effect how many records are actually returned from the datasource.

Unfortunately, since you don't have direct access to the database and the web-service doesn't offer any other methods, then the best you can probably do is cache the data. Luckily asp.net makes cacheing data quite simple. The Cache object is rather like Session, except you only have one instance per application, not per user.

It looks like you're fetching all products from the web service, then doing the sorting and paging from within your web page. This means that you're pulling back more data from the web service than you need at any one time. Does the web service provide the facility to pass arguments representing the required page, page size and sort order? If not, maybe you should discuss the possibility of adding these features with the third party who are providing the service.

If this isn't possible, how often is the product list updated? If it is updated relatively infrequently, you could use the ASP.NET cache to store the results of the web service call locally. The cached data source could be set to expire on, say, an hourly basis. This way, users viewing the page will see a reasonably up-to-date list of products.