iBATIS 101 – A biased view
[UPDATE] Charlie's blog posting on the subject. Well worth a read!
To summarize iBATIS allows you to use XML files to map your business objects to your SQL statements. It seems pretty easy to learn and is being proposed as an alternative in the Java and .NET worlds to (n)Hibernate and other ORMs.
If you have a big budget and a dba with nothing better to do than hand craft the SQL to optimize all of your statements, I can see where iBATIS would fit in. Instead of having to put up with generated SQL you can get a SQL guru to hand code and fine tune all of your queries.
On the other hand, while I agree that an ORM (in the ColdFusion world that would be Reactor, Transfer, ObjectBreeze, etc.) can run into limitations when trying to generate your SQL, I also think that the vast majority of queries in most applications can absolutely be generated automatically. Proponents of iBATIS point out that the database is often the biggest bottleneck in application performance (which is usually correct). However, to hand tune hundreds or thousands of SQL queries before any of them have been proven to be a performance bottleneck seems to me to be premature optimization in the first degree. I’d rather use an ORM for most of my queries and then just tweak the ones that need a little more TLC than my generator can provide.
I see the benefits in java or .net of something taking care of all of the low level plumbing of data access, and I understand that people sometimes get overwhelmed when learning Hibernate (I'm still working my way through a pretty large book on the topic), so I guess this would work for either small projects where the team didn't have Hibernate experience and didn't want to have to learn the whole ORM API just to speak to a few tables, and maybe it would work for use cases where you were using a lot of stored procedures or had unique requirements that the generated SQL just wasn't addressing.
Is anyone attracted to iBATIS? Is anyone doing something like this in CF? Is anyone seeing benefits in this that I’m missing? Any thoughts or opinions gratefully received!
One thing to bear in mind is that .net and Java don't have cfquery! A lot of the time saved is that you don't have to create a connection and build a connection string and close the connection and handle connection pooling and who knows what other stuff that is getting better (especially in .net) but is still way more painful than just cfquery. One of the reasons I still love CF!
But you are right. You still write all the SQL. It does allow a different person to write the SQL to a well specified interface so if you have a dba who writes your SQL or your project is all stored procedure based it does a nice job of handling separation of concerns, and it makes it easier to reuse queries by abstracting them into a DAO in case you weren't already doing that. Learning curve is also pretty shallow, but to me it is an awful lot of extra work compared to just hand coding DAOs. Only use case I can think of for a CF version would be if you had a db team and a programming team and wanted to document and enforce the interface between te two via a well thought out XML specification. For that, I guess iBATIS would be cool.
Let me know how it goes with db4o. I've never really seen much adoption of object oriented databases, but it would be interesting to hear about your experiences.
Glad you had a good time with iBATIS, but if you use CF and want to speed up development of common queries I'd recommend checking out Transfer or Reactor if you had the time, and if you do a lot of projects with many objects and plenty of simple CRUD, Hibernate/nHibernate have a very steep leaning curve, but can make you way more productive in the long run. Hibernate is really the kind of ORMs and it is pretty amazing all the things it is capable of doing.
I appreciate the comments from you and others here. As has been asserted, it may make sense more for those who don't want to (or need to) get into a full ORM. And while it may seem counter to CFML ("we've got CFQUERY"), I made the argument in the blog entry that it may still be of value over that (yet not as heavy as a full ORM solution).
Again, not knocking any approach. Just wanted to throw it out for discussion, so glad to see you rekindle it.
Firstly, many thanks for adding the link. Sorry I was in a rush and while I credited you, I really should have provided the link. Apologies for that and thanks for doing what I should have done! I'll try to be less hasty in future :->
The reason I mentioned your post was I wanted to highlight that I certainly would not have come across iBATIS back then (or would have tuned it out) if you hadn't posted. Wasn't trying to suggest you were advocating it (again, link would have helped with that :-<).
I agree it is a great thing to look at. I think the value is less in CF than in Java or .NET, but I absolutely agree it has some use cases and think it is ALWAYS a good thing when someone raises a "anyone looked at x" kind of post. I think people will see from the comments above the key use cases, but while this isn't something that works for me, I'd love to hear from anyone doing a CF iBATIS port as you can never have too many toolkits out there!!!