No. :-) Collections suck. They're slow, not type safe, harder to
test, less descriptive, unpredictable and generally crap. Using
collections for a domain model in my opinion is a horrible idea.
But I still love you Vic.
Clinton ;-)
On Sat, 15 Jan 2005 12:53:34 -0600, Vic Cekvenich <[EMAIL PROTECTED]> wrote:
> Just to state the obvious alternative:
> <select id="login" resultClass="java.util.HashMap"
> cacheModel="sec_cache">
>
> Using collections!
> I have done a few iBatis projects ;-) , and this is what I do.
>
> Try that for a bit. This also avoids having to write any beans. That
> gets old too. (I learned a lot from Flex's use of Associative Arrays aka
> Collections. Flex is writen by the guy that wrote Poolman/ I forget his
> name ).
> I know that there are some prejedices FOR beans... but try it; you may
> be suprised. The strongest part of Java lang is collections.
> It also makes it loosley coupled.
> Imagine using DisplayTag w/ iBatis. I can add/remove/hide/compute
> columns in either the view or the DAO w/ out chaning the middle or the
> other side.
> And... it encourages working on SQL as a set (or rows). So you return an
> ArrayList of Maps.
> The performance impact is minimal even uder load.
>
> The last +: CoR chains. I used this, and as we know... it is
> execute(Context) where context is a map. What a easy way to pass arround
> arguments and results.
> So ... VO/DTO can easily be a collection.
>
> ot: think NO_ENTRY should be default, that is my favoirte PITA.
>
> .V
>
>
> Clinton Begin wrote:
>
> >Hi all,
> >
> >Okay, I'm sick of typing out parameter map and result map stanzas, how
> >about you? We'll always have them, as they are a primary structure
> >for an SQL map, and future tools may use them. However, I want to
> >implement a shorthand method. The approach would be similar to inline
> >parameter maps. For example (excuse the % tokenization, it's just for
> >example purposes).
> >
> ><select id="getPersonByID" parameterClass="int" resultClass="e.g.Person">
> > SELECT
> > PERSON_ID AS %id%,
> > FIRST_NAME AS %firstName%,
> > LAST_NAME AS %lastName%,
> > BIRTH_DATE AS %birthDate,javaType=date,jdbcType=DATE%
> > FROM PERSON
> > WHERE PERSON_ID = #value#
> ></select>
> >
> >Some caveats:
> >
> >1) The SQL is less pure, and more mangled. Although initially this
> >looks bad, I think most people use the built-in logging or P6Spy to
> >grab the real statements anyway. Also, for initial SQL development,
> >it doesn't reduce the ability for a database admin to write the SQL
> >(or if it does in your case, you still have the option of an external
> ><resultMap>).
> >
> >2) Dynamic SQL performance may be slightly impacted (no more so than
> >inline parameters, which is the only way to do dynamic SQL anyway).
> >
> >3) The paramter tokenization may get out of hand. We already know we
> >want a new syntax, and this will give us the additional motivation to
> >move in that direction. Currently we have #parameters#,
> >$substitutions$ and with the above example of inline results, we'd
> >have %results%.
> >
> >An option for different tokenization might be something like:
> >P{parameter}, S{substitution} and R{result}. This is similar to the
> >Ant ${property} syntax, and will have fewer conflicts with potential
> >new dynamic SQL languages (like velocity, which reservs #), and
> >certain databases (like JDE that often uses # in column names).
> >
> >This would completely eliminate the need to write <resultMap>
> >elements. Of course we'd need to forward some additional properties
> >like groupBy to the <select> element, and also include a facility for
> >the upcoming <subclass> element. But neither of those pose a problem.
> > This is mostly a change to the XML parser, and not to the
> >functionality of the framework.
> >
> >Thoughts?
> >
> >Cheers,
> >Clinton
> >
> >Thoughts?
> >
> >
> >
> >
>
>
> --
> RiA-SoA w/JDNC <http://www.SandraSF.com> forums
> - help develop a community
> My blog <http://www.sandrasf.com/adminBlog>
>
