Joe Hertz wrote:
The point is... I use ArrayList of Maps now for my DTO,VO and ever as a message object for WS/SOA.
Wherever I used to use a bean, now I use a collection, and I like DynaMaps.
I think I'm buying what you say in a big kinda way.
Cool.
I worked for years in an architecture that eschewed many OO concepts
as creating more work than they saved.
I of course see a lot of productivity and velocity (rate of development) of useing OO w/ Collections. You can have BaseMap or BaseList, etc.
Its universe was something like this-
A Database contains a map of Table Objects A Table object contains an array list of Record Objects. A Record object contains a map of Field Objects. Etc
Even silly JSF uses RowSet as DTO. (RowSet is realy a ArrayList of HashMaps. Rows of Columns)
I look at it like this:
-SQL is a Set oriented lang.(row by row processing is exponentialy slower)
-iBatis can allways return an ArrayList of Hashmaps (so I do not have to write a bean, or keep the bean up to date w/ my Domain - I consider iBatis a domain).
- Flex (RiA) can recive a ArrayList of HashMap as natie Associative Array. (so cool that Collection is a DTO - I can even change form model w/o creating new beans or new gets/sets)
- Since this design works w/ Flex, I might as well use it in JDNC.
Or the short version: In Java, we represent Sets as/is a Collection.
For Struts, that means not a FormBean, but a FormModel (a map that maps to fields).
No more mutiple "CustomerBeans" on large projects and having to add get/set when view or domain evolves. It's dynamic and losly coupled.
I am not sure if I am advocating not mastering beans 1st, what with late binding issues they solve. But once you know beans, then... dynamic.
hth, .V
Done properly, something like this could be infinitely reusable no matter
what the application.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
