Reading Sun's 'Core j2EE patterns' (Alur, Crupi, Malks, Prentice Hall, 2001) they recommend to use the 'Value List Handler' (353) pattern to solve the problem of a large results set that can be generated via a findall() type query (or any query that returns a large result set) on an Entity Home. This pattern utilises a session bean and a DAO (basically) to return an iterator over a set of value objects.
My questions are these;
(WebSphere specific) to make a DAO (data access object) independant of the EJB system that uses a read-only JDBC query, is it possible in this object to access the WebSphere connection pool? Generally, how is this achieved? (apologies for this basic Websphere question I have not used JDBC within the Websphere framework yet as so far it has been avoidable).
The Value List Handler pattern has the client going back and forth to the session object (the Iterator) for each and every object in the list. I could see this as advantageous where the client is for example accessing each value object one by one and performing an operation on all or nearly all of them. But in situations where the entire list must be presented 'all at once' (e.g. for manual selection by a user and so on) in the client is it sensible to do this? Surely in this case it would be better to send a collection of serialisable objects back to the client in one hit? ...
Following on from that; rather than implement a set of heavyweight value objects for each returned object, would it be sensible to implement a lightweight value object which comprises of nothing but (e.g.) the PrimaryKey object and a simple descriptor field like a Name field, perhaps using a collection such as a HashMap (Namestring and EJBKey pairs) or an Enumeration of lightweightValueObjects? Because in this instance, the client will see a list of Names, select one for use, and then retrieve the full details of the selected lightweight object from the session facade and an associated value object factory. Is it sensible to perform this extra trip to the server rather than send possibly 1000s of much larger, but potentially unused objects?
Your thoughts on the best design for this are appreciated.
I have had my own copy of the book for barely a week, so treat my response accordingly.
>(WebSphere specific) to make a DAO (data access object) >independant of the EJB system that uses a read-only JDBC >query, is it possible in this object to access the >WebSphere connection pool?
I have this same question: How best to let the DAO use the pool while still staying EJB independent?
The best solution we could come up with is to have the EJB obtain a DataSource from JNDI and then pass the DataSource as a constructor argument to the DAO class. All the DAO class needs to know about is DataSources; the DAO doesn't need to import "javax.ejb.*"
Once we get fancy and start using a DAO factory, the DataSource will simply be passed to the factory, which will then provide it to the DAO.
>The Value List Handler pattern has the client going back >and forth to the session object (the Iterator) for each >and every object in the list.
All I can add here is that I don't believe that the Value List Handler is limited to single fetches. The pattern includes "getPreviousElements" and "getNextElements", and "getSubList" which allow clients to specify exactly how large a chunk to bring back.
>would it be sensible to implement a lightweight value >object which comprises of nothing but (e.g.) the >PrimaryKey object and a simple descriptor field like a >Name field
This is probably done quite frequently. Hopefully someone can describe a nice pattern for a "subset" value object.
thanks for your thoughts.
especially the idea passing the datasource object to the DAO in it's constructor. i don't know why this didn't occur to me, probably though because i've not used any jdbc yet with websphere (or any jdbc 2.0 at all). my system so far is mostly only dealing with relatively small enums of objects that belong to a certain user, it's only now that I come to make the 'admin' interface where potentially all objects must be dealt with that i have to face this question.
yesterday i tried to solve the problem of lightwieght objects by interposing a new interface in a heirarchy like this;
AllMyObjectsInterface <-- LightweightSomeObjectInterface <--HeavyweightSomeObjectInterface
then minimally the lightweight object interface defines just its primary key and another field, in that case the name, that is presented to the user in lists or what have you, and the heavyweight interface extends that with all the other information.
I only did it so far with a single object that i'm dealing with currently. The problem I see with it is that I'll have to write two interfaces for every object, lightweight and heavyweight, two concrete classes of valueobject, and so on.
So for the moment I will only implement it on a per-object basis when I determine I require a lightweight version. I can either cast objects up to a lightweight or use a method in the heavy object directly to obtain a light version.
Also because these objects are then arranged into a tree-like structure (a straight out taxonomy, not the type of thing one would use the 'flyweight' pattern for because of the 'extrinsic state' of each object). So there is a another sort of valueobject that extends the heavy object (no interface at this point - just direct inheritance - but I will make into a proper 'Composite' pattern later). This tree extends the heavy object by implementing the code to traverse the tree structure within it.
Therefore already the 'heavyweight' object is kind-of a medium-weight object (no taxonomy). The factory of course knows how to make the tree object from either a heavy or light object if it is needed.
If anyone has some ideas about other patterns to use here, particularly with the taxonomy,i'd appreciate hearing them.
We currently implement something similar using stateless session beans returning serialisable sublists of lightweight value objects (to the web tier which display jsp or send onto webstart clients). This avoids going to the session object for each and every object in the list. The client preferences decide the size of sublists returned depending on what info is being displayed.
At the moment we havent solved the "I'll have to write two interfaces for every object, lightweight and heavyweight, two concrete classes of valueobject, and so on" problem.
I dont have 'Core j2EE patterns' but I was just browsing the sun site and came across the following description of the Value List pattern, which mentions the use of sublists: