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.
Most 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 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 ssociating 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.
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 value objects. The client requests the ValueListHandler to provide the query results as needed. The ValueListHandler implements an Iterator pattern to provide the solution.
The class diagram in Figure illustrates the Value List Handler pattern.
Figure Value List Handler Class Diagram
Participants and Collaborations
The sequence diagram in Figure shows the interactions for the Value List Handler.
Figure Value List Handler Sequence Diagram
This interface may provide iteration facility with the following example methods:
Depending on the need, other convenience methods can be included to be part of the ValueListIterator interface.
This is a list handler object that implements the ValueListIterator interface. The ValueListHandler executes the required query when requested by the client. The ValueListHandler obtains the query results, which it manages in a privately held collection represented by the ValueList object. The ValueListHandler creates and manipulates the ValueList collection. When the client requests the results, the ValueListHandler obtains the value objects from the cached ValueList, creates a new collection of value objects, serializes the collection, and sends it back to the client.
The ValueListHandler also tracks the current index and size of the list.
The ValueListHandler can make use of a DataAccessObject to keep separate the implementation of the database access. The DataAccessObject provides a simple API to access the database (or any other persistent store), execute the query, and retrieve the results.
The ValueList is a collection (a list) that holds the results of the query. The results are stored as value objects. If the query fails to return any matching results, then this list is empty. The ValueListHandler session bean caches ValueList to avoid repeated, unnecessary execution of the query.
The ValueObject represents an object view of the individual record from the query's results. It is an immutable serializable object that provides a placeholder for the data attributes of each record.
Java Object Strategy
The ValueListHandler can be implemented as an arbitrary Java object. In this case, the ValueListHandler can be used by any client that needs the listing functionality.
For applications that do not use enterprise beans, this strategy is useful. For example, simpler applications may be built using servlets, JSPs, Business Delegates, and DAOs. In this scenario, the Business Delegates can use a ValueListHandler implemented as a Java object to obtain list of values.
Stateful Session Bean Strategy
When an application uses enterprise beans in the business tier, it may be preferable to implement a session bean that uses the ValueListHandler. In this case, the session bean simply fronts an instance of a ValueListHandler. Thus, the session bean may be implemented as a stateful session bean to hold on to the list handler as its state, and thus may simply act as a facade (see “Session Facade”) or as a pro
Implementing the Value List Handler as a Java Object
Consider an example where a list of Project business objects are to be retrieved and displayed. The Value List Handler pattern can be applied in this case. The sample code for this implementation is listed in Example as ProjectListHandler, which is responsible to provide the list of Projects. This class extends the ValueListHandler base class, which provides the generic iteration functionality for all Value List Handler implementations in this application. The ValueListHandler sample code is listed in Example. The ValueListHandler implements the generic iterator interface ValueListIterator, which is shown in Example. The relevant code sample from the data access object ProjectDAO, used by ValueListHandler to execute the query and obtain matching results, is shown in Example.
Example Implementing Value List Handler Patternpackage corepatterns.apps.psa.handlers;
The Value List Handler is a generic iterator class that provides the iteration functionality.
Example Implementing Generic ValueListHandler classpackage corepatterns.apps.psa.util;
Example ProjectDAO classpackage corepatterns.apps.psa.dao;
Example ValueListIterator classpackage corepatterns.apps.psa.util;
J2EE Related Interview Questions
|Java Script Interview Questions||Adv Java Interview Questions|
|J2SE Interview Questions||Core Java Interview Questions|
|Java Struts Interview Questions||Hibernate Interview Questions|
|JavaServer Faces (JSF) Interview Questions||Java 8 Interview Questions|
|JavaFX Interview Questions||NHibernate Interview Questions|
|Spring MVC Framework Interview Questions||The Java Debugger (JDB) Interview Questions|
J2ee Platform Overview
Presentation Tier Design Considerations And Bad Practices
Business Tier Design Considerations And Bad Practices
J2ee Patterns Overview
Presentation Tier Patterns
Business Tier Patterns
Integration Tier Patterns
Epilogue J2ee Patterns Applied
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.