In many use cases, there is a generic requirement to show the list of data to user. User should be able to see the list of data, to perform search and sorting operations on this data. User should also be able to navigate to any data record anytime. This requirement demands to fetch the large amount of data from database and list it on UI for the user. Then this data can be filtered using various search criteria and can be sorted also depending upon user input. Approach to fetch the data can be different depending upon architecture and implementation of application, like data can be fetched directly from database in case of embedded applications, or 2 tier architecture or through some services in 3 tier architecture. The process flow used to be like:
- Take inputs from user what kind of data she wants to see
- Interact with database directly or through service (depending upon architecture) to get this data
- Display this data to user
- Filter or sort the data depending upon user action on UI
For example, open google.com. Search for any word. You will get search results in list form, and various page number given at the bottom of the page to navigate to different pages.
Now if there are thousands of data records in database for given inputs, all of this data can not be shown to user in one go. Showing this on same screen will be having problems like:
- It will not be a good experience for user, as she will need to scroll up and down a lot and information will be unreadable practically.
- It will not be good for performance of application, as application may get out of memory or may face slow response due to large amount of data in memory, or data transfer from database.
To solve first problem mentioned above, we need to divide the data in small parts to show the user one part at a time. For example, we can divide data in parts having 50 records each. Then each of the parts can be shown to user one by one. Once user see first part, she can request for next or previous part and hence corresponding 50 records can again be shown on screen to user. These parts are called pages, and this process is called pagination - which divides the large data in pages (having limited records) and show these to user.
To implement this, one possible solution is, to retrieve all required data from database using any of the design strategy and store this data at UI layer. UI layer can have the logic to divide this data in pages and to show this to user. UI will also implement the navigation control for users using which user can request the previous or next page, or can go to a specific page directly.
However, with this solution, one problem is still pending which is - impact on performance of application due to large amount of data in memory at a time. Another issue is, fetching large amount of data from Database will take time due to large time of query execution and due to overhead of large data transfer over the network. If this data is coming through some service, the service response will itself become slow due to serialization / de-serialization process.
So how to solve this problem now. Solution is to have something which can fetch only required amount of data (or bit more) from database or service and keep only this data at UI. For this, there should be some component implementation on client and server which can work in tandem like-
- Understand which part of the data user wants to see (i.e. which page)
- How to retrieve that requested part of data (page) from database
- How to transfer data from server to client in coarse grained structure (using DTO) and may be only that data columns which are required for listing
- How to communicate with server based on user input to see any other page, or for searching or sorting
- How to store all inputs given by user for a request like, what kind of data, search or sort parameter etc; to avoid asking it again and again for every next or previous page
Once we have this system in place, that would solve all above problems. Client will get only that amount of data which is requested by user on UI. That means there would not be any unnecessary pressure on memory of client, and no pressure on network bandwidth or database performance.
This approach is called server side pagination, where pagination data is managed at server side. Previous approach explained above was client side pagination, here whole data is fetched to client and then managed to show in pages.
Without any doubt, server side pagination is a better to have performing applications. Client side pagination is comparatively easy to implement and hence may be considered for simple applications.
In next article, we shall be discussing about the design of components which can support the server side pagination. Stay tuned!!
4 comments:
Thanks sir for explaining pagination in simple word waiting for next part....
Is next part available now?
Thanks for asking. It will be available in next week.
Next part is available at http://www.vedantatree.com/2013/06/design-for-server-side-pagination.html
Post a Comment