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>
