|
J2EE Blueprints Design Pattern
Paged List
|
|
|
|
|
Paged List
|
|
|
Make large, remote collections efficiently traversable by accessing
the collection elements in pages.
|
|
|
Access remote collections in a network-efficient way
|
|
|
Object Structural
|
|
|
Distributed database applications often require the user to choose
from a arbitrarily-long list of items. The client is only capable of
presenting a sublist of the whole list at anyone time, and the user
may be interested in only a small subset of the entire list. For
example, in the Java Pet Store sample application, the JSP page
product.jsp uses a Paged List to access lists of
catalog items. Transmitting the entire catalog as a list of objects
to view would be extremely inefficient from the point of view of
network traffic and latency. Very seldom is a user interested in
looking at an entire catalog: users generally browse long lists in
search of something specific. In many cases, the list being accessed
is so large that it's not even realistic to have the entire list in
memory on the server at once.
The Paged List pattern provides a way to present a paged, scrolling
list of items to the user, while minimizing network traffic, server
load, and latency. Instead of receiving the entire list, the client
code accesses a "ListChunk", a sorted list of items of a given
length, starting at a given index. Instead of transmitting the
entire list, the server-side implementation simply queries the
catalog and returns the appropriate number of items, starting in the
appropriate place.
|
|
|
Use the Paged List pattern:
- to display the result of the query
- to present sublists of a large list of items to the user
- when list length is too long to transmit to the client in
its entirety, or when the full list is unnecessary
|
|
|
 |
Figure 1. UML Diagram for the Paged List.
|
|
|
|
|
- displays long list of items to the user
|
|
- abstracts access to sublist of virtual list on the server
|
|
- abstracts implementation of an individual list
- provides access to sublists of the virtual list being
browsed
- must be Serializable
|
|
- abstracts access method for sublist request
|
|
- accesses database to produce requested sublist
|
|
|
|
|
- fetches sublist from Model, based on user actions
- displays sublist to user
|
|
- abstracts access to a PagedList object
|
|
- encapsulates a sublist of a particular type
- result set type of Model's sublist method(s)
- despite its name, does not implement
PagedListInterface, but rather is the return type of the
PagedListInterface method that accesses a sublist
|
|
- receives sublist requests from ClientView
- forwards requests to enterprise bean
|
|
- receives sublist requests from Model
- acquire sublist from database and transmit to Model
|
|
|
|
-
Efficient access to large lists on the
server. Clients can present "windows" on large lists
present in the database, without needing to upload all of the
information in the list.
-
Potentially higher number of server hits.
Since the entire list of data are not been transmitted in a
single request, each list browse results in a potentially large
number of sublist requests.
|
|
|
-
Trade-off between network transmission load and
server hit frequency. Smaller sublists result in a higher
number of smaller server requests, as users browse through the
large virtual list on the server. If the sublist size is too
small, users will do more paging, resulting in a larger average
number of remote calls. Larger sublists require more network data
transmission, but result in fewer accesses. The client's list
display capacity defines the upper limit of sublist size.
With a fast network, it's usually better to fetch the largest list
practical for the display device, to increase the chance the user
will find what's being sought. A slow network, however, makes
smaller lists preferable, since the overhead for transmitting a
larger lists results in more latency and user frustration.
-
Sublist size may be client-dependent.
Clients may differ in their list-display capacities, maybe due to
display limitations, network bandwidth, or other factors unknown
at deploy time. Ideally, the client should be able to indicate to
the Model how many items it requires.
-
Caching can improve user experience and a
decrease network load. If the client-side implementation of
the PagedListInterface caches the result sublists, subsequent
accesses to the list can be retrieved from a cache, instead of the
network. The cache may need automatically to limit its own size
(for example, using a high-watermark scheme to delete the
least-recently-used entries.) This technique assumes either
relatively stable data on the server (so the cache is never out of
date with server data), or an active cache that can receive
updates from the model when server data is modified.
|
|
|
Paged List is implemented in the Java Pet Store by the class
ListChunk.java
The ListChunk class is used by, among other classes,
CatalogDAO.java
|
|
|
In the Java Pet Store, the Catalog component uses Paged List to
display the results of a user search, to list product categories,
and to browse products from the catalog.
|
|
|
Iterator
|