CFArgument - ColdFusion ORMs Are a Waste of Time?

This week Peter and I discuss the usefulness of learning the popular Object Relational Mapping (ORM) solutions for ColdFusion. There are a small group of solutions with Transfer being the most widely known but which also include Reactor and DataFaucet. Indeed, it has already been announced that ColdFusion 9 (Centaur) will include Hibernate integration.

Peter Bell
Reactor and Transfer were both valiant efforts by skilled developers to create ORMs in ColdFusion. But compared to Hibernate, they're limited and unsophisticated. As a ColdFusion developer, if you haven't already learnt Transfer or Reactor, I'd recommend getting a book on Hibernate instead so that you're learning the industry leading ORM.

Brian Rinaldi
Telling most ColdFusion developers to learn Hibernate is like explaining that the only way to catch a mouse is with a bear trap. While there are certainly many large and complex ColdFusion applications that may benefit from Hibernate, my guess is that most are things like, for example, a small intranet applications to handle data entry CRUD. In this case, using Hibernate over Transfer is overkill. Transfer is quicker to learn, easier to integrate and will get the job done just as well.

Peter Bell
Well, Transfer or Reactor are definitely better than hand writing (or generating) your SQL or trying to write your own ORM. And if you have a simple use case, they may work fine. But I see time and time again on the Transfer mailing list people running into problems that have been solved in Hibernate but are not part of the Transfer code base yet such as issues with handling inheritance hierarchies. People seem to be putting so much effort into those kind of cases that they'd be better off just moving to a platform that's pretty well solved those problems.

Brian Rinaldi
Now some of these arguments may change when we finally see the Centaur Hibernate integration details. However, even that proves the point as its intent is to make something that is hard to integrate and to learn and make it quick and easy to use for the average ColdFusion application.

Peter Bell
But the fact is that Hibernate integration is almost here. Centaur will be released this year, Railo will probably integrate Hibernate this year, with CFGroovy you can use GORM and leverage the Grails ORM wrapper around Hibernate, and Joe is working on his Hoagie stack to integrate Hibernate into CF apps. By the end of the year there are going to be multiple proven ways for CF developers to integrate hibernate into their applications.

Why not plan for that and start building a skill set you'll be able to leverage for years to come by buying a book like "Java Persistence with Hibernate"? (The latest edition of what was "Hibernate in Action")

Brian Rinaldi
Well, first of all, we don't know the specifics yet about the Hibernate integration in ColdFusion 9. We've been told that if you know Hibernate, you'll be able to leverage that by manually creating mapping files and such. Still, the intent will be to make it easy to use and learn and specifically not require an extensive knowledge of Hibernate. So, in the end, perhaps your time is better spent on other skills.

Peter Bell
From my experience with Hibernate, you really need to "get" Hibernate to use it effectively or you're going to end up with an inefficient solution for handling inheritance hierarchies and a world of hurt with eager fetching loading up your entire object model every time you try to return a bean! I also think that by learning Hibernate you really get an understanding of ORM - it's strengths, trade-offs and issues.

Brian Rinaldi
Nonetheless, I suspect that the mailing list for Transfer is a poor place to gauge its general usefulness since, by its very nature, you'd only hear about people having issues with it.

Peter Bell
LOL, OK, that's a *really* good point. Man, I must be distracted today - you're kicking my ass :)

Brian Rinaldi
If I were building a small to medium sized ColdFusion application I would leverage Transfer as opposed to adding the complication and high learning curve of learning Hibernate (and thereby making the application take that much longer to build)

Peter Bell
The point of something like Hibernate is that once you've learnt it, you've learnt it. My question is whether it's really worth slowing down that process by learning a less capable solution that you're likely to outgrow. Anyway, the problem with "small to medium sized applications" is that they don't always end up small to medium sized!

Brian Rinaldi
Well, you won't catch me arguing with you that if you have the time and interest, you could benefit from learning Hibernate. However, I still maintain that for most applications built with ColdFusion, Transfer is the faster and easier route that will handle most if not all of the functionality you require from a basic ORM. I think you would find that someone with no Java or ORM experience could be up and running with Transfer within a day or two (granted there is more to it but the basics are easy to learn). You certainly can't argue the same for Hibernate.

Peter Bell
Well, with something like GORM, you really can be up and going in a day or two, but I agree that the CF integration isn't there yet. I'll give you this argument (hey, you gotta win one!) and agree that for simpler apps and if you have no background with ORMs, Transfer or Reactor will allow you to get started more quickly and dip your toes in the water. But I'm still going to maintain that once you start to run into the limitation of the CF based ORMs, rather than wrestling with them you should really check out Hibernate and get a fully featured ORM working for you instead.

Brian Rinaldi
What do you mean "this one"? You clearly were judging the prior debates solely on verbosity. ;)

Peter Bell
Oh no. Not only are you a poor loser, but also a poor winner? That'll teach me to throw you one :)

Well, we take in over $300 million a year with our cold fusion based solution and we have not needed an ORM yet. Does that say enough? But, we've shelled out a lot of money at the author's of an ORM to use it on a non-revenue based solution that we outsourced. It jsut came along as a 'gift' from the company that we outsourced to.

cfwheels has an easy to learn and use orm already built into the framework. hibernate is so overkill and manually writing mappings is so 1995. the activerecord pattern is a proven architecture for interacting with your database and it's available now in cfwheels. i would suggest giving it a try.

http://www.cfwheels.com

DataFaucet, part of the onTap framework was not mentioned and utilizes the activerecord pattern AFAIK - would that be worth learning? Anyone here using it?

What is meant by learning? Do you mean learning as in specific technical aspects or catching onto the bigger concepts?

Without having done either, I would think starting with Transfer would allow a person to start to grasp the concepts. Yes, there's going to be some specific things for Transfer that you won't use again. But isn't that a bit like being afraid to throw away code? My concern would be that people starting down this path, many of which may not have a great grasp of OO in general, will foremost get the bigger picture items. Would jumping in and using hibernate cause those of us who aren't quite so brilliant to spend a lot of time spinning our wheels on little issues just getting something working with Hibernate instead of taking a smaller step using a different ORM and being able to concentrate more on learning the concepts?

I feel like Hibernate really isn't the monster it's made out to be. Sure, if you want to leverage everything it offers you're in for a lot of learning. But if you just want to use basics, or say, use it to do the equivalent of what you do with Transfer, I don't think it's that hard. Also, from what I've seen of the Centaur integration, it's pretty easy to get going with simple cases. So I'm with Peter for the most part, might as well learn Hibernate. However, if you know you won't be able to upgrade to Centaur any time soon, then you might we well served to invest time in Transfer/DataFaucet/Reactor.

I think there is a MAJOR argument against Hibernate that seems to of been missed. The argument that it's going to be in CF9 very soon is TERRIBLE. a) Not everyone can just "run right out" and buy CF9 b) Many of us out here support legacy CF apps (6,7,8) that are owned and maintained by someone else, and we cannot force them to change c) I **don't ** want to limit sales of my software based on what version of CF the potential buyer might have. Talk about shooting yourself in the foot.

The answer is something like Transfer or Reactor - it works with more versions of CF and it is here TODAY - tested and limitations known.

Am I the only one that sees that value in this?

The talk probably should be considered based on needs. What your are looking for and what is the size of your application.

I am a guy who always preferred to code without depending any DB platform with DAOs etc. but I also wonder the strategies to utilize the SQL Server features/powers in ORM based structures. If you are focusing a specific DB platform I really would like to use the power of the DB platforms and I feel that this is not easy in ORMs and having some of the code based on a ORM and others default SQL would be not the best.

Still it looks like what you need and what is the know how level in your team etc.

Thanks for sharing this great conversation. :)

"manually writing mappings is so 1995"

hah! so funny, I was thinkin the same thing, as I was reading the argument...

"Railo will probably integrate Hibernate this year"

Is this true? I really wish they'd integrate something similar to what cfwheels has... an activerecord schema, I feel is the most modern approach to an ORM! not wanting to start an activerecord/transfer/hibernate debate here, but another config (xml) file added to my application is just getting overkill!

Well, to be fair with Hibernate, you no longer need to use xml config files, you can just use JPA annotations embedded in your java code. Not sure that'll be feasible with a CF integration of Hibernate, but they make things easier in different ways, so...

The real problem with ColdFusion ORMs is not the "RM", it's the "O" - meaning that what they can realistically achieve is hobbled by CF's object implementation. You could morph this whole argument into "Trying to do OOP in CF is a waste of time".