AppFuse Refactorings Part IV: Replacing Hibernate with iBATIS
This is a continuing series on what I'm doing to make AppFuse a better application in Winter/Spring 2004. Previous titles include: Changing the Directory Structure
, Spring Integration and Remember Me refactorings.
- - - -
On my last project, we ported an existing JSP/Servlet/JDBC app to use JSP/Struts/iBATIS. In the process, I got to learn a lot about iBATIS and grew to love the framework (although I prefer to spell it iBatis). It was super easy to port the existing JDBC-based application because all of the SQL was already written (in PreparedStatements). Don't get me wrong, I think Hibernate is the better O/R Framework of the two, but iBATIS works great for existing databases. The best part is that iBATIS is just as easy to code as Hibernate is. For example, here's how to retrieve an object with Spring/Hibernate:
List users =
|
And with Spring/iBATIS, it requires a similar amount of Java code:
List users = getSqlMapTemplate().executeQueryForList("getUser", user);
|
The main difference between the two is that iBATIS uses SQL and Hibernate uses a mapping file. Here's the "getUser" mapped statement for iBATIS:
<mapped-statement name="getUser" result-class="org.appfuse.model.User">
SELECT * FROM app_user WHERE username=#username#;
</mapped-statement>
Spring makes it super easy to configure your DAOs to use either Hibernate or iBATIS. For Hibernate DAOs, you
can simply extend HibernateDaoSupport and for iBATIS DAOs you can extend SqlMapDaoSupport.
Now to the point of this post: How I replaced Hibernate with iBATIS. The first thing I had to do was write the XML/SQL mapping files for iBATIS. This was actually the hardest part - once I got the SQL statements right, everything worked. One major difference between iBATIS and Hibernate was I had to manually fetch children and manually create primary keys. For primary key generation, I took a very simple approach: doing a max(id) on the table's id and then adding 1. I suppose I could also use the RandomGUID generator - but I prefer Longs for primary keys. Hibernate is pretty slick because it allows easy mapping to children and built-in generation of primary keys. The ability to generate the mapping file with XDoclet is also a huge plus.
As far as integrating iBATIS into AppFuse, I created an installer in contrib/ibatis. If you navigate to this directory (from the command line), you can execute any of the following targets with Ant. It might not be the most robust installer (it'll create duplicates if run twice), but it seems to work good enough.
install: installs iBatis into AppFuse
uninstall: uninstalls iBatis from AppFuse
uninstall-hibernate: uninstalls Hibernate from AppFuse
help: Print this help text.
All of these targets simply parse lib.properties, build.xml and properties.xml to add/delete iBATIS stuff or delete Hibernate stuff. They also install/remove JARs and source .java and .sql files. If you're going to run this installer, I recommend running "ant install uninstall-hibernate". Of course, you can also simply "install" it and then change the dao.type in properties.xml. This will allow you to use both Hibernate and iBATIS DAOs side-by-side. To use both Hibernate and iBATIS in an application, you could create an applicationContext-hibatis.xml file in src/dao/org/appfuse/persistence and change the dao.type to be hibatis (like that nickname ;-). In this file, you'd have to then define your transactionManager and sqlMap/sessionFactory. I tested this and it works pretty slick. Click here to see my applicationContext-hibatis.xml file.
Some things I noticed in the process of developing this:
- Running "ant clean test-dao" with iBATIS (28 seconds) is a bit faster than Hibernate (33 seconds). I'm sure if I optimized Hibernate, I could make these numbers equal.
- The iBATIS install is about 500K, whereas Hibernate's JARs are around 2 MB. So using iBATIS will get you a slightly faster and smaller AppFuse application, but it's a bit harder to manipulate the database on the fly. There's no way of generating the tables/columns with iBATIS. Instead it uses a table creation script - so if you add new persistent objects, you'll have to manually edit the table creation SQL.
Hibernate is still the right decision for me, but it's cool that iBATIS is an option. Even cooler is the fact that you can mix and match Hibernate and iBATIS DAOs.
Posted by Unknown on February 12, 2004 at 05:15 PM MST #
Posted by Jason on February 12, 2004 at 05:41 PM MST #
Jason - I saw that last night too! WTF? ;-) Just kidding - I think Rick is doing it over me because he has the connections and is doing many more presentations at the conference. I doubt they'd ever hire me to do just one. Besides, since I've never been to NFJS, I'd hate to have to present at my first one!
The real question is - which version of AppFuse will he present on? I hope to release a couple more versions before the Denver NFJS...
Posted by Matt Raible on February 12, 2004 at 07:07 PM MST #
* Completely new API and XML document structure. Simpler, cleaner and more flexible.
* Extended stored procedure support. Finally output parameters are completely transparent.
* Better support for auto-generated keys. For those of you stuck with having to use them ;-)
* Improved support for arrays and lists. If your objects have array types as properties, this will work well for you.
* XML parameters and results. Direct XML to database integration. No intermediate beans or maps.
* Type aliases. These make it easy to deal with long and repetetive class names.
* Smaller footprint and fewer dependencies. Under JDK 1.4 you only need iBATIS and Commons Logging.
* Improved performance. Thanks to enhanced lazy loaders and straight-through paths.
* 99% backward compatible with 1.x. First question: what's the 1%? Answer: You tell me. :-)
I'll give iBATIS a try once the beta is over with. I'd rather not learn the old style and have to convert. But iBATIS looks more like something I can use than Hibernate, partially because of my environment -- our organization tends to do database work up-front before "real" coding begins, plus everyone already knows SQL and the maps are easy to learn. Hibernate is a whole new ballgame, so it will take some time to learn/experiment with and find ways to get the other "business" developers comfortable with. I'll give both a try in the next few months and see what shakes out.
BTW, when you say Denver NFJS, do you mean the one in Broomfield? I thinking of attending that one, if not then the one in Phoenix (I'm in Albuquerque).
Posted by Gerry on February 12, 2004 at 09:44 PM MST #
Posted by Matt Raible on February 12, 2004 at 11:20 PM MST #
I'm torn about NFJS, though, as the TSS Symposium in Vegas is within a few months of the NFJS ones in Broomfield and Phoenix, and I'm positive my boss won't spring for both. I'll probably end up at NFJS if only because it costs less.
BTW, I'm not sure if you've covered it much, but what's your current opinion on JavaServer Faces? How much of AppFuse could port to JSF, or could AppFuse be refactored to work on both? Probably worth discussing in a separate blog post. Just curious...
I'll try not overdo the fomatting next time... :-)
Posted by Gerry on February 13, 2004 at 05:15 AM MST #
Posted by Matt Raible on February 13, 2004 at 06:41 AM MST #
"I just got an email on the agenda for the next No Fluff in May, which included: "AppFuse: Start your next Struts application with a bang! (Intro) by Rick Hightower" Perhaps attending this session will help shed some light for you on Appfuse. ;-) Seriously though, I was expecting to see your name next to that one. "
"Jason - I saw that last night too! WTF? ;-) Just kidding - I think Rick is doing it over me because he has the connections and is doing many more presentations at the conference. I doubt they'd ever hire me to do just one. Besides, since I've never been to NFJS, I'd hate to have to present at my first one! "
"The real question is - which version of AppFuse will he present on? I hope to release a couple more versions before the Denver NFJS... "
I will be presenting on AppFuse 1.4. I've used AppFuse 1.3 and Spring on a few projects. I am a really big fan of Matt's work. I've worked with a lot of the tools and technologies in AppFuse for several years. Matt an I met when he came to Tucson. Matt is a sharp dude. I am sure if he decides to go on tour, I will have to pick a different topic. When we met in Tucson, Matt agreed to let me be a commiter on AppFuse. I have some experience getting AppFuse to work with JBoss, and I have some real-world Spring experience to boot. I am writing about AppFuse in my new Struts book on Sourcebeat as well.
Posted by Rick Hightower on March 07, 2004 at 10:33 PM MST #
Matt - yours is one of the clearer explanations of the differences between iBatis and Hibernate. I've been trying to research both, but have come to one basic question, hopefully you or someone else here can provide some more insight.
I have a Struts app that uses some pretty complex sql, and the database is denormalized just a bit for performance reasons. I can see iBatis being quite useful here. My question though is if I were to do this app again from scratch and use Hibernate, is there a performance penalty vs. the tried sql I'm using above? Would hibernate benefit from a different database design / table structure? I have this idea of Hibernate making multiple queries to the db.
Posted by Paul on May 24, 2004 at 04:44 PM MDT #
I guess it just depends on what you want - ORM or Hibernate? If you really want to use Hibernate, I'm sure it would be possible - I've just found it a lot easier to migrate JDBC -> iBATIS than JDBC -> Hibernate. As far as I can tell, iBATIS gives you all the same advantages (i.e. caching) as Hibernate.
Posted by Matt Raible on May 24, 2004 at 04:58 PM MDT #