Excerpt | ||
---|---|---|
| ||
Mapping Java Objects to the results of SQL Queries |
Panelinfo | ||||
---|---|---|---|---|
| ||||
|
...
|
(This really belongs off in it's own little section, but I can't do side bars in wiki markup!)
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 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 | ||||
---|---|---|---|---|
| ||||
|
Introduction
While there's nothing particularly special about the use of 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. <br/>
Note: While this example uses Spring & 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.
Overview
Dramatis Personae ;
- 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
SqlMapClientDaoSupport
and make the DB call using a definition in an SqlMap relating to the Item.
...
- Entry.map.xml : IBATIS SqlMap definations, one per operation.
Another take on the above may be obtained by using the Abator code generator tool - See below.
...