表示层模式:Value List Handler—值列表处理器模式

Context
The client requires a list of items from the service for presentation. The number of
items in the list is unknown and can be quite large in many instances.
Problem
Most Java 2 Platform, Enterprise Edition (J2EE) applications have a search and query
requirement to search and list certain data. In some cases, such a search and query operation
could yield results that can be quite large. It is impractical to return the full result set when
the client's requirements are to traverse the results, rather than process the complete set.
Typically, a client uses the results of a query for read-only purposes, such as displaying the
result list. Often, the client views only the first few matching records, and then may discard
the remaining records and attempt a new query. The search activity often does not involve
an immediate transaction on the matching objects. The practice of getting a list of values
represented in entity beans by calling an ejbFind() method, which returns a collection of
remote objects, and then calling each entity bean to get the value, is very network expensive
and is considered a bad practice.
There are consequences associated with using Enterprise JavaBeans (EJB) finder
methods that result in large results sets. Every container implementation has a certain
amount of finder method overhead for creating a collection of EJBObject references. Finder
method behavior performance varies, depending on a vendor's container implementation.
According to the EJB specification, a container may invoke ejbActivate() methods on
entities found by a finder method. At a minimum, a finder method returns the primary keys
of the matching entities, which the container returns to the client as a collection of
EJBObject references. This behavior applies for all container implementations. Some
container implementations may introduce additional finder method overhead by associating
the entity bean instances to these EJBObject instances to give the client access to those
entity beans. However, this is a poor use of resources if the client is not interested in
accessing the bean or invoking its methods. This overhead can significantly impede
application performance if the application includes queries that produce many matching
results.
Forces
The application client needs an efficient query facility to avoid having to call the
entity bean's ejbFind() method and invoking each remote object returned.
A server-tier caching mechanism is needed to serve clients that cannot receive and
process the entire results set.
A query that is repeatedly executed on reasonably static data can be optimized to
provide faster results. This depends on the application and on the implementation of this
pattern.
EJB finder methods are not suitable for browsing entire tables in the database or for
searching large result sets from a table.
Finder methods may have considerable overhead when used to find large numbers of
result objects. The container may create a large number of infrastructure objects to facilitate
the finders.
EJB finder methods are not suitable for caching results. The client may not be able to
handle the entire result set in a single call. If so, the client may need server-side caching and
navigation functions to traverse the result set.
EJB finder methods have predetermined query constructs and offer minimum
flexibility. The EJB specification 2.0 allows a query language, EJB QL, for
container-managed entity beans. EJB QL makes it easier to write portable finders and offers
greater flexibility for querying.
Client wants to scroll forward and backward within a result set.
Solution
Use a Value List Handler to control the search, cache the results, and provide the
results to the client in a result set whose size and traversal meets the client's requirements.
This pattern creates a ValueListHandler to control query execution functionality and
results caching. The ValueListHandler directly accesses a DAO that can execute the
required query. The ValueListHandler stores the results obtained from the DAO as a
collection of Transfer Objects. The client requests the ValueListHandler to provide the
query results as needed. The ValueListHandler implements an Iterator pattern [GoF] to
provide the solution.