It's not a showstopper. But the two biggest issues I see are: 1) Type Safety. Doesn't need explaining.
2) Performance. With a JavaBean, each property is essentially method call and the setting of a reference. With a HashMap, each property is a method call, an object creation (Entry), a call to .hashCode(), a possible array resize, a possible rehash, a possible collision and call to .equals(). Cheers, Clinton On Thu, 16 Dec 2004 14:13:04 -0600, Vic Cekvenich <[EMAIL PROTECTED]> wrote: > I don't see it. > > Even w/ Struts at Ziff Davis I allways had my return type set to HashMap > in iBatis, so I NEVER have to do mapping of fields in xml . > What I do now in version 2 is returh a HashMap; an ArrayList of HashMaps > realy. (how ActionScript in Flex worked, they call it associative array > to bind to a datagrid) > > I send iBatis Collections via Hessian (SoA) to Swing Table Model (JDNC) > and bind it. I deploy via WebStart. Works great. > Also I can map to a Swing Form Model (jGoodies Form Layout). On a submit > action I do commons validator in Swing like I would in Struts. So a user > enters a valid date or whatever. (way ot: I even do dynamic "tiles" in > Swing w/ add/remove in JPanels). > Swing actions send in arguments back bia Hessian to Ibatis, also a Map. > (The dispacher is commons-chain, and Context is a Map). > No where do I have getters/setters or field mapping. > Map is a Map of Objects so I know the class/instance Of the Object. > I can add fields in select statment in ibatis and it just shows up in my > Swing table w/o any code changes. Losley coupled. Zero mapping of fields > in XML or in Java. > Also, if I careate a computed or a fake field, I just put that property > in the Map. > Collections good. > > (and I have 100 page or so of docs/tutorial on sandraSF.com, if someone > wants to know more about the "wrong" way. So I locked iBatis to Hessian > for nice remote service. Also I locked iBatis to JMX so I can flush the > cache via JMX. And like I said, everything "server side" is Chain, so it > was easy to implement a remote Lucene DAO. I was planing to donate parts > to iBatis like JMX and CRUD dispatcher. Not a single bean, get set. Just > select * and jTable Model that is based on a collection). > > In any case, I do not see a problem, but would like to learn what others > see as a potential problem that I do not see, since I am about to go live... > So if somone has the time or the will to educate me, I am all ears. > > .V > > > Clinton Begin wrote: > > >I'll back up Kris on that one. In my experience, the result of Map > >based domain models isn't pretty. > > > >It depends on what you're doing. I'm sure there are places where it > >works well, but it's certainly the exception, not the rule. > > > >Cheers, > >Clinton > > > >On Thu, 16 Dec 2004 16:46:05 +0000, Kris Jenkins > ><[EMAIL PROTECTED]> wrote: > > > > > >>>>This is just one reason why I always recommend using JavaBeans for 99% > >>>>of your work. Maps are inconsistent, unpredictable, not typesafe and > >>>>slow. > >>>> > >>>> > >>>Hm. > >>>I acctualy feel the other way, that 99% of time, Collections > >>>implementations such as Map and List are good. > >>>This way you can be loosley coupled. > >>>I used to like Beans, but have moved to collections, ( I learned from > >>>MM Flex.) > >>> > >>> > >>:-/ That doesn't sound like loose coupling to me - that sounds like > >>throwing away type safety. By that logic, Perl would be inherently > >>loosely coupled, which it isn't. > >> > >>-- > >>Kris Jenkins > >>Email: [EMAIL PROTECTED] > >>Blog: http://cafe.jenkster.com/ > >>Wiki: http://wiki.jenkster.com/ > >> > >> > >> > >> > > > > > > > > > > -- > RiA-SoA w/JDNC <http://www.SandraSF.com> forums > blog <http://www.sandrasf.com/adminBlog> >
