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.
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 .
iBATIS Dynamic SQL
<select id="getCategories" parameterClass="SearchClass"
<iterate prepend=" categoryId IN"
open="(" close=")" conjunction=",">
<isNotEmpty property="categoryName" prepend="AND">
name LIKE ( #categoryName# || '%')
So, that is what the mapped statement looks like, and here is how you would call it:
Search WWH ::