views:

434

answers:

2

Hi, 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.

+1  A: 

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.

pmarflee
I've contacted the third party to see if it's possible. If it is, will it simply be a case of passing the relative arguments (such as number of items per page etc..)? Or do I have to change my method entirely?]The product list is actually the shopping cart of the user. Therefore, it's only updated when they update it manually.
keyboardP
@TenaciousImpy: how many items are likely to be in a user's shopping cart at any one time? If we're only talking about single/double figures, your current approach is probably adequate. Sorting and paging the results in the service would probably be overkill. In order to avoid fetching the contents of the shopping cart on every change of page, you could cache the contents of the cart in the ASP.NET Session when the page first loads. Session state is per-user, not per-application, so each user will get their own session state.
pmarflee
@pmarflee - Thanks for the help. I'm guessing there will be around 60 items or so per user. I may resort to sessions if the third party is getting too many unnecessary hits. For now, I'll leave it as is.
keyboardP
+2  A: 

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.

Dan Diplo
I thought of using Cache, but the product list is not universal. It is essentially the user's shopping cart, so it will be unique for each user.
keyboardP
In that case I wouldn't worry - I doubt anyone is going to have many products in a shopping basket. If you really did want to cache the results you could use Session. If you are worried about memory then remember you can store Session state in SQL Server.
Dan Diplo
Thanks for the help Dan. On average, there'll be around 60 items per basket. I'll take things step by step. If there's too many hits on the third party's server, I'll use in proc sessions. If this proves to be too memory intensive, I'll use SQL Server Sessions. Thanks!
keyboardP