This book shows you how to build an app with JHipster, and guides you through the
plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks
so you understand the underpinnings of your great application.

- - - -
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:

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.

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.

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.

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.

Anonymous - if you read up on iBATIS - you'll understand how it works. It basically just has binding parameters in its SQL syntax.

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...

Thanks for the iBATIS post, Matt! But to be a bit more on-topic than the previous commenters (Matt included!), the iBATIS 2.0 beta says it will do PK creation. Here's the lowdown on what's new (from SQL Maps 2.0, my bolding as to what appears to be worth noting):

* 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).

That's <u><font face="arial" color="#006600">EXACTLY</font></u> the NFJS document I'd seen. I saw the JDJ article earlier today and checked out the NFJS website for more info. I really like the list of presenters and the presentations. The one in Denver isn't scheduled until November. Lucky for you Broomfield is a stone's throw away (relatively speaking in a stretching it kinda way). Nice town, though - I enjoyed taking a few classes at the Sun facility out there a few years back. It'd be good to see what's new in the area as it was booming back then.
&nbsp;

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...

Gerry, I think JSF is way over-hyped. I think it's something that will work nicely for Swing developers. However, as an HTML developer - I think it makes things too complicated. It's main <em>ray of light</em> seems to be vendor support - as in tools to create JSF apps. I do have a JSF UI for AppFuse on the roadmap, but I don't know if it'll be worth my time. IMO, I think tried and true solutions like Struts, WebWork and Tapestry will probably prevail over the long haul.

"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.

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.

If you have an app that is currently using JDBC and you'd like to convert it to using an ORM solution - I'd highly recommend using iBATIS. The main reason is because it's <em>very</em> easy to do. Most of the work involves moving the SQL statements out of your .java files and into .xml files. If you use Spring, you don't even have to worry about managing connections! Using Hibernate is easiest when you have full control over your database structure - and especially when you're not worried about data migration.

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.