Extended datasource APIs with the ASPxGridView

Recently there have been a number of technical questions raised about how the ASPxGridView works, with large datasets in general, and with LINQ in particular.

Let's go back to basics first, and especially the user experience that our grids afford. I'm not talking here about how to develop with them, what you have to link up and where, just the end-user features and benefits. For a start there's sorting (click on the column header), grouping (drag the column header to the grid's grouping panel and drop), filtering (type in a simple criteria as text). There's also extra information that can be shown: the column and group totals and so on.

Unbeknownst to the user but still crucial are the paging capabilities of the grid: the user doesn't have to wait extended lengths of time for data to be shown in the grid as they manipulate the grid. Of vital importance with this paging is that it still works well when the user is grouping records. By that I mean that if the user groups on City, say, and the grid displays a page of cities, all collapsed, then the paging subsystem only returns those city records, and not all the detail records making up the groups. Expand a city, and the paging subsystem returns the records needed to expand that group and fill the grid.

So, back at the beginning of last year (2007), when we were designing this new grid, we determined pretty quickly that we'd need an intelligent paging subsystem that could help with all the user experience scenarios we envisaged. In particular, we really wanted to make sure that our story with grouping was compelling, since the grids out there just weren't. And since we had much of the functionality in XPO (eXpress Persistent Objects — our ORM solution — already, it made sense to use it, and so the famous IListServer interface was born along with its first implementation.

A lot of customers saw that IListServer was good, but they wanted other implementations to cover other data sources and scenarios. At the beginning of this year (2008), we released our implementation of it that used a LINQ provider, and thereby supporting all manner of data sources.

Now, with LINQ being available, the question arises whether we should even do this intelligent paging at all. The standard LinqDataSource does efficient paging, so why not use that? Cut out the middleman!

As it happens, although it does sound like an attractive idea, it won't work. Let me rephrase that. Not "work", but "work well enough". In the last couple of days, as an experiment, the guys on the team implemented support of the standard LinqDataSource inside ASPxGridView. And it works very well for the basic feature of paging records into the grid. It doesn't work at all well for grouping and filtering, and certainly doesn't work for creating summary or total values.

So what should we do? Should we add an option to switch the grid between this hobbled version and the fully functional version (I'm thinking about it from the end-users viewpoint here)? Or should we just accept that our grid's end-user functionality is of prime importance, even if the developer has to jump through a couple more hoops to get there?

Of course, this is not the final word. We'll continue to investigate this issue to see if there is some other solution we can explore. So, even if the current answer is "business as usual", stay tuned.

Free DevExpress Products - Get Your Copy Today