Using hashtable to return data instead of VOs
Using hashtable to return data instead of VOs
We need to produce jsp's with specific data of a EJB. If we create one VO for each screen we'd be tying my web layer into the ejb layer. If I use a generic VO we'd be wasting bandwidth (we use a expensive satelite). We create a design that asks for especific data (sending a page code and retrieved in the server using reflection and xml for setting up) that populates a hashtable and then serializes it back to the client. Have someone used this design ? If this design is strange what's the best solution.
Emerson
> Using hashtable to return data instead of VOs
a VO is a Pattern, which can be implemented using a Hashtable (or any type of Collection) as its implementation.
As my response to your previous post on this topic points out, a VO is quite commononly a complex Object, it is not a simple 'value'. It can range from a single byte/field/row/table/database/...
> We need to produce jsp's with specific data of a EJB.
> If we create one VO for each screen we'd be tying my
> web layer into the ejb layer.
Make you VO reflect the data encapsulated by a Use-Case/Scenario, the view/screen is only one part of that requirement.
The granularity of you VO is very important, it should not be too small or too large, it is an issue of balance, and experience helps, typically a VO should reflect the granularity of your EJB's. If you access a Customer EJB, you probably need to think CustomerVO, etc.
> If I use a generic VO
> we'd be wasting bandwidth (we use a expensive satelite).
Table/Record/Field Level Status (Dirty Flagging) are a natural extension for VO's, and are more-likely to save bandwidth than manually tuning your VO's by allowing the client side to effectively cache data, and save bandwidth on an UpLink.
Do not be drawn into the Anti-Pattern (trap) of using large numbers of fine grained VO's, this only appears more efficient, and wastes bandwidth in a different way by requiring a larger control overhead.
Furthermore remember ALL bandwidth is getting cheaper and expertise more expensive (Moores Law meets Economics 101), flexibility and adaptability are the order of the day, for lowest TCO.
If you can afford the XML overhead over binary data, you can afford this strategy.
> We create a design that asks for especific
> data (sending a page code and retrieved in the server
> using reflection and xml for setting up) that
> populates a hashtable and then serializes it back to
> the client.
> Have someone used this design ?
> If this
> design is strange what's the best solution.
The description is lacking in detail to draw solid conclusions, but it seems like a reasonable architecture.
