ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: was Re: Information about changelog - collections vs beans
Date Thu, 16 Dec 2004 20:42:25 GMT
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().


On Thu, 16 Dec 2004 14:13:04 -0600, Vic Cekvenich <vin@friendvu.com> 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
> ><krisajenkins@yahoo.co.uk> 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:  kris@jenkster.com
> >>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>

View raw message