Question about the Value List Handler Pattern
Hi all,
I'd like to implement the Value List handler Pattern for displaying result of a search.
Basically the Collection is made of 2 elements
TravelDepartures which holds a Collection of Itineraries
and TravelReturns which holds a Collection of Itineraries too.
What is the correct way to implement the pattern ?
Should I have a ValueHandler super-class which holds an instance of List Handlers for Departures and one instance for ListHandlers for Returns ?
or should the objects TravelDepartures and TravelReturns hold an instance of its own ListHandler ?
Hope I explained myself well.......
Thanks
Francesco
The client object gets a reference to the ValueListHandler object and calls the method(s) to view and select items from a search of business records.
There is only one ValueListHandler object in the pattern. The ValueListHandler gets a reference to a DataAccessObject (DAO) and the DAO builds the data object (in terms of the design pattern, this is termed ValueList).
To implement this design pattern you also need to code an Iterator. The Iterator object is created by the ValueList object and is used to iterate over the records.
So, in summary to correctly implement this design pattern you must also be familiar with the Data Access Object and Iterator design patterns.
Also, keep in mind that there would be only one record set. This set would consist of the departures and returns. Depending upon you skill level, you may try to integrate the two data sets into one ValueListHandler implementation. Or, an easier route would be to implement two ValueListHandler implementations (one for each record set respectively).
Hello!
Thanks for your reply !
Well I decided to implement a single ListHandler with 2 ListIterator inside, one for departures and one for arrivals. ( I call setListDepartures and setListArrivals to set the correct list of flights)
I have posted the core of the pattern, I'd be grateful if somebody
could give me some feedback (positive or negative of course)
As you can see the business delegate uses a Service Locator to find the flightEJB.
The EJB is implemented as a stateful session bean.
The SFSB holds a reference to the ShoppingCart object.
The Shopping Cart Object, in turn, holds a reference to the ValueListHandler and its relative setter/getter.
Is it correct to hold the ValueListHandler in the ShoppingCart ?
Thanks
Francesco
public class SearchBusinessDelegate {
......
FlightServiceLocator flightServiceLocator =
FlightServiceLocator.getInstance();
flightEJB = flightServiceLocator.findFlightService();
flightEJB.searchFlights(depCity, destCity, depDate, returnDate );
}
public class FlightBean implements SessionBean {
// Shopping cart of Stateful Session Bean;
ShoppingCart cart;
........
// Get Dao Object from the factory
SearchProcessorDAO searchDAO =oracleFactory.getSearchProcessorDAO();
// Get List of Departures
List coll1 = searchDAO.searchFlights(depCity, destCity, depDate, returnDate);
// Get List of Arrivals
List coll2 = searchDAO.searchFlights(depCity, destCity, depDate, returnDate);
// Set departures list in the shopping cart
cart.getListHandler().setListDepartures(coll2);
// Set Arrivals list in the shopping cart
cart.getListHandler().setListArrivals(coll1);
}
public class ShoppingCart implements Serializable {
ValueListHandler listHandler = new ValueListHandler();
public ValueListHandler getListHandler() {
return this.listHandler;
}
......
}
> Is it correct to hold the ValueListHandler in the ShoppingCart ?
This is an implementation detail and beyond the boundaries of a design pattern. There is no one correct way to implement any design pattern. There are many ways to correctly implement a design pattern. Whether one implementation is better than another depends upon many other factors such as how it exexcutes, whether the business requirement is satisfied, ease of maintenance, debugging, extensibility, etc. That said, if the implementation works and you are able to satisfy the requirement, then it is "correct". If it does not work and the requirement is not satisfied, then it is not "correct".
From a design stance, to answer your question, either the Session EJB or the Shopping cart can have the ValueListHandler as a field. My personal preference would be to have it in the Session EJB.
The core purpose of the Value List Handler pattern is to get the records of business entites that are to be used in the application at some point as Entity EJB. The ValueList is a list of business records that have corresponding Entity EJB implementations in the application. One uses the pattern to avoid having to instantiate a whole bunch, this effects performance. From the results of the search, then you application creates the Entity EJB from the records of interest, and then the application works with the Entity EJB for business processing.
If you are not creating Entity EJB, then you really don't need the Value List Handler and could use plain old DAO pattern.
>
> Thanks
> Francesco
>
> > public class SearchBusinessDelegate {
>......
> FlightServiceLocator
> flightServiceLocator =
>
> lightServiceLocator.getInstance();
>
> flightEJB =
> flightServiceLocator.findFlightService();
>
> flightEJB.searchFlights(depCity, destCity,
> depDate, returnDate );
>
> }
>
>
>
> public class FlightBean implements SessionBean {
>
>// Shopping cart of Stateful Session Bean;
> ShoppingCart cart;
> ........
>
>// Get Dao Object from the factory
> SearchProcessorDAO searchDAO =
>oracleFactory.getSearchProcessorDAO();
> // Get List of Departures
> List coll1 =
> searchDAO.searchFlights(depCity, destCity, depDate,
> returnDate);
>
>// Get List of Arrivals
> List coll2 =
> searchDAO.searchFlights(depCity, destCity, depDate,
> returnDate);
>
> es list in the shopping cart
>
> art.getListHandler().setListDepartures(coll2);
>
>// Set Arrivals list in the shopping cart
>
> art.getListHandler().setListArrivals(coll1);
>
> }
>
>
>
> public class ShoppingCart implements Serializable {
>
> ValueListHandler listHandler = new
> ValueListHandler();
>
> public ValueListHandler getListHandler() {
> return this.listHandler;
>
> ......
>
Well I have examined your answer and then I agree with you. With Session Bean it's not much worthy to implement this pattern. It does't give utility to the whole process and on the other hand it adds another layer.
I'll keep this implementation for a different scenario
Thanks for your reply
Francesco
