Implementing Ajax true pagination in asp.net using the ObjectDataSource control

The newly added ListView control in ASP.net 3.5 is a great control for page data binding and interface layout, and it has made a lot of improvements on the basis of the ASP.net 2.0 GridView, where users can control more elements and develop more flexibility. The individual feels that ListView is more handy than the DataGrid and Girdview when used. The ListView control itself does not have paging functionality, but with the newly added DataPager control in asp.net, we can easily set pagination for the data in ListView, which hardly requires a developer to write a line of code to put the ListView control on the page. Set the layout and DataSource, and then add a DataPager control, set its Pagedcontrolid property to ListView Id,pagesize to set the number of data bars to display per page. Then set the pagination style in the fields (you can definitely do without the pipe style, ASP.) NET defines the paging UI according to the built-in styles, and when you run the Web program, you see a ListView page that supports pagination, and the whole process is simple. In ASP.net 3.5, Microsoft separates data-bound controls from pagination controls so that users can set up pagination anywhere on the page and define a variety of page styles according to their needs, and the paging control can control any data-bound control that passes through Pagedcontrolid property to specify that, basically, for paging operations, developers can do whatever they want. How to use the ListView and DataPager controls is not the focus of this article, and interested readers can check out Microsoft MSDN and I think it should be much more detailed than I said.

First of all, the principle of data paging. When we are developing a Web application for a data-bound page, often encountered in the case of more data, in order to prevent the page becomes too large load data slow problem, we will be a page to display the data through pagination to complete, users visit the page through the paging function to view the data in different pages, This is a very good solution, and almost all of the program designers and developers will be happy this way to use pagination to display the data on the page, this is no problem! The problem is the way the page is paginated.

Generally, the simplest way to do this is to read all of the page's data into the cache medium at once, which is typically the server's memory, and then display only one page of data at a time. This approach is easy to implement, and almost all of the data-bound controls that support pagination have been used in this way before asp.net, so many asp.net beginners have used this approach to develop pagination data-binding pages without noticing any problems. Yes, the most simple and effective method in program development is generally not a problem, and the standard controls provided by Microsoft do so, what are the problems? For some small web applications, this really does not matter, because it involves a small amount of data, even if we read all the data into memory, at best a few trillion, a little more than more than 10 trillion, a few 10 trillion. If these data are pure text (in general, we keep the data in the database are text information), a few 10 trillion data is already thousands of records, now the server hardware conditions are relatively good, memory in the G level above, to deal with this data is not alone. However, if a table in the database reaches billions of records, and some fields are storing file data (that is, binary data), so it is not ideal to read all of the data into memory at once, and this time you need to read the data in a "true paging" way.

In most cases, we still need to use a "real paging" approach to get the data. Given the starting position of each page record (or the index of the page), and given the number of bars and total records for each page of data, we want to fetch only the current page's data each time. Each time the user paging, based on these conditions from the database to take part of the data binding to the page, this can greatly reduce the cost of the server, and a large amount of data is not a problem. This approach seems to be ideal, however, combined with the needs of users, we will find that even if the use of "real paging" way to page the data access, but also encounter problems. Just imagine that in today's Ajax-infested web world, sites that use Ajax to improve the user experience abound, and if you happen to have an AJAX-provided pagination data binding page, the problem arises. Because the Ajax user experience effect is a partial refresh of the page, in the Pagination data binding page, the page will update the paging data at a faster rate after the user clicks the paging button, which is pretty good for the user, but greedy users may want to try clicking the paging button frequently, Even the crazy user dot paging button, this time your application because of the need to go to the database to get the paging data very often too late to update the data on the page and the script error, the end of the user experience is the page paging function is not normal, the program crashes.

The combination of "true pagination" and "fake pagination" can be a very effective solution to the problem mentioned above. I refer to the first type of data paging described above as "fake paging", while the second type of data paging is called "true paging". The combination of the two pages, that is, one-time reading of n-page data to the cache, paging, as needed to determine whether to get the data directly from the cache or to reload the data from the database into the cache. After all, it is much more efficient to load data from the cache. This way, each time the user clicks the paging button, as long as the data exists in the cache, it can load the data at a very fast rate, and reload the new N-page data from the database to the cache if the cache expires or the user gets more data than is cached. Of course, the process of updating the cache allows you to use synchronization in Ajax to limit the user's UI actions in this process.