THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Excerpt | ||
|---|---|---|
| ||
Mapping Java Objects to the results of SQL Queries |
| Panel | ||||
|---|---|---|---|---|
| ||||
|
| Info | ||||
|---|---|---|---|---|
| ||||
First, just to help clarify things, there's two iBATIS components, the Data Mapper framework (a.k.a. SQL Maps) & the iBATIS Data Access Objects. They're packaged together but completely independent and here we're just comparing/discussing the former. The key documentation As of December 2006, iBATIS has been simplified to perform one function, and only one function: data mapping. While iBATIS used to support a DAO layer, this has been deprecated in favour of using Spring and IoC. This article will stick to discussing the data mapper; for more information on the DAO implementation, please refer to the Spring framework documentation (specifically here). The key documentation for iBATIS is the Developer Guide, with the very latest here in the SVN repository. OK, on to Hibernate vs. iBATIS...<br>
Fundamentally, iBATIS maps Java Objects to the results of SQL Queries, whereas Hibernate maps Java Objects directly to database tables, traditional Object-Relational Mapping. The benefits of Hibernate are that it automatically generates all the SQL for your and the cache invalidation can be more fine grained. iBATIS is more flexible especially if you are a strong SQL query writer. You have control over exactly how the SQL queries are written. Another way of looking at it to say that Hibernate works well if you have mostly standard queries(CRUD, Find by Criteria, etc.) and if you are designing your object model first. If you are working with a legacy system or a schema designed by a DBA, iBATIS often makes a better choice. Of course, we're not discussing absolutes here, they're both much better than raw SQL! The thing with iBATIS is that there isn't a whole lot of magic, and you get full control over the SQL, so you can see what's going on and how to change it. Compared to other frameworks, it has a shorter learning curve, but can take more time to develop and maintain, since you have to write all your queries (using Abator can short-circuit this step) and if your object model changes you have to go through all your queries and make sure to make all the necessary changes to reflect the changes in your object model. | ||||
| Panel | ||||
| borderStyle | solid||||
| title | Table of contents | |||
|
Introduction
While there's nothing particularly special about the use of IBATIS iBATIS within a Wicket application, the normal Wicket requirement of ensuring that things that you store in your pages are Serializable mean that you may need to be careful how you store references to DAO-type objects.
The following is intended to suggest one way in which this might be done.
Note: While this example uses Spring & and the SpringBean annotation, neither are strictly required, but they do simplify things enough that I felt it was worth using them, even without any previous knowledge of them.
...
- EntryDao : An interface describing the DAO operations we want, e.g. count, find, load, save, delete
- EntryDaoImpl : An implementation of the DAO. For Spring/IBATIS, this will extend
SqlMapClientDaoSupportand make the DB call using a definition in an SqlMap relating to the Item. - Entry.map.xml : IBATIS SqlMap definationsdefinitions, one per operation.
Another take on the above may be obtained by using the Abator code generator tool - See below.
...
Entry.map.xml
IBATIS SqlMap definationsdefinitions, one per operation.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMap
PUBLIC "-//ibatis.apache.org//DTD SQL Map 2.0//EN"
"http://ibatis.apache.org/dtd/sql-map-2.dtd">
<sqlMap namespace="Entry">
<select id="get" parameterClass="string" resultClass="package.name.model.Entry">
SELECT name, value, LAST_CHANGE as lastChange FROM TB_ENTRY WHERE name = #value#
</select>
<!-- Use Entry object (JavaBean) properties as parameters. Each of the
parameters in the #hash# symbols is a JavaBeans property. -->
<insert id="insert" parameterClass="package.name.model.Entry">
INSERT INTO TB_CONFIG (NAME, VALUE, DESCRIPTION, LAST_CHANGE) VALUES (#name#, #value#, #description#, SYSDATE)
</insert>
<update id="update" parameterClass="package.name.model.Entry">
UPDATE TB_ENTRY
SET
VALUE = #value#,
DESCRIPTION = #description#,
LAST_CHANGE = SYSDATE
WHERE NAME = #name#
</update>
<!-- Use primitive properties as parameter for delete. -->
<delete id="delete" parameterClass="string">
DELETE FROM TB_ENTRY WHERE NAME = #value#
</delete>
</sqlMap>
|
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- Wicket Application -->
<bean id="wicketApplication" class="com.zaryba.topup.web.config.TopUpConfigApplication"/>
</beans>
|
...
iBATIS'
...
sqlMapConfig.xml
This contains the 'global' settings for IBATIS iBATIS and the collection of SQL maps in use. When using together with Spring, it can be very concise...
...
Note: If we don't want to/can't use @SpringBean then there are other options available, e.g. [ storing the DAO in the Application|Spring#Application_Object_Approach ], etc.
Misc Notes
Paging
Ibatis's iBATIS SqlMapClientTemplate does have a queryForList(String statementName, Object parameterObject, int skipResults, int maxResults) method, but note that it works by obtaining all the elements(keys) from the DB then just returning the selected part of the list. If wanting to handle this more efficiently, it's down to the (DB-specific) SQL.
...
Abator is a code generator for iBATIS that will introspect examine a database table/tables and generate iBATIS artifacts artefacts that can be used to access the table(s).
...