Java Reference
In-Depth Information
more legible than our Java example, and likely this is due to the fact that it is not
secured with parameterized
SQL
. As far as maintainability goes, things become a bit
more complex. With a stored procedure, we are left to depend on the database
administrator to deploy our
DDL
scripts when we deploy our application. With the
Java example, our
SQL
stays with the developer and can be deployed with the rest
of our code base.
Stored procedures can have varying mileage depending on the database you
are using and how well its internal language is suited for complex tasks. When
using stored procedures for Dynamic
SQL
, you end up with the same complexity
of the Java example—no security gain, no performance gain, and a more compli-
cated deployment. The other thing to note is that we didn't even include the Java
code it takes to call the stored procedure in the first place. If we were drawing up
an evaluation, it might be hard to choose between straight Java or a stored proce-
dure. This is where
iBATIS
comes in.
8.5.3
Comparing to iBATIS
After examining straight Java and stored procedures for Dynamic
SQL
, we are left
wanting something that can give us performance, security, and productivity. List-
ing 8.17 shows the same Dynamic
SQL
from listings 8.15 and 8.16 but uses the
iBA-
TIS
SqlMap
s framework for Dynamic
SQL
.
Listing 8.17
iBATIS Dynamic SQL
<select id="getCategories" parameterClass="SearchClass"
resultClass="CategorySearchCriteria">
SELECT *
FROM Category
<dynamic prepend="WHERE">
<iterate prepend=" categoryId IN"
open="(" close=")" conjunction=",">
#categoryIds[]#
</iterate>
<isNotEmpty property="categoryName" prepend="AND">
name LIKE ( #categoryName# || '%')
</isNotEmpty>
</dynamic>
</select>
So, that is what the mapped statement looks like, and here is how you would call it:
queryForList("getCategories",searchObject);
