Only statements that use the explicit SQL string substitution syntax are at risk in
i BATIS . Consider this quick example. The following statement allows for a
dynamic table name and column name:
SELECT * FROM $TABLE_NAME$ WHERE $COLUMN_NAME$ = #value#
Such a statement is flexible and useful in some situations, but exposes you to SQL
injection and should therefore be used judiciously. This is not an i BATIS problem,
as you'd have the same problem no matter how you executed such a statement.
Always be sure to validate user input that will have an impact on dynamically con-
structed SQL statements.
Reducing the complexity
While JDBC is a very powerful tool, it is also a very low-level API . To help better
understand where i BATIS fits in your application, let's draw an analogy.
Years ago, to create a web application with Java, you would have to start at the
HTTP level, and write an application that listened to a port and responded to
requests. After a few years of this, Sun provided us with a Servlet specification that
we could use as a starting point so that we would not have to do this sort of socket-
and port-level development. Not long after that came the Struts framework, which
took web development with Java to the next level.
Most Java developers today would never seriously consider writing a web-based
application starting at the HTTP protocol or even with straight Servlets—instead
they would get a Servlet container like Tomcat and use it with the Struts frame-
work (or something similar like Spring or WebWork).
To draw a parallel to persistence, when Java 1.0 came out, there was no JDBC
specification. Developers doing database work had to figure out how to talk
directly to the database via its native network protocols. With the release of ver-
sion 1.1 of Java, JDBC entered the picture, and we were given a starting point for
working with databases instead of having to work with sockets and ports. The i BA-
TIS framework is to database development what Struts is to HTTP . Although you
could write applications by opening a port to the database server or using straight
JDBC , it is much simpler to write your application using a tool like i BATIS and let-
ting it deal with Connection , Statement , and ResultSet objects instead of mixing
them into your business logic.
Just as Struts does, i BATIS provides you with an abstraction to suppress a great
deal of complexity that comes along with the lower-level components that it uses.
It does not completely remove them from your application, but it lets you avoid
dealing with them until you need to.
Search WWH ::