Questions about ORM in ColdFusion 9

So the ColdFusion 9 public beta has been released, and now everyone can play with it. I’m excited to hear what the community as a whole has to say about it. One of my favorite features is ORM or Object Relational Mapping.

As I’ve been traveling around for the user group tour, I’ve heard a few questions about it, and I wanted to share these thoughts.

Are you forcing us to use ORM?

Absolutely not – cfquery and its related tags aren’t going away. ColdFusion is about making what you want to do easy. If you want to work with queries, work with queries–we’ve made it pretty easy, as I’ve said before. But a number of customers wanted to work with databases in an easier, object-oriented way. A lot of developer effort has gone into doing that with various ColdFusion Open Source projects. It makes sense then that we would strive to make this easy too. That’s “too” as in “also,” or “additionally,” or “alternatively.” Or in other words, if you think ORM might have value, use it; if not, keep working the way that works for you because you are not required to use it.

In fact, we were actually able to expand the features of cfquery when we added ORM. In order to use ORM you have to add a datasource to the This scope in your application.cfc. Well when you do that, any cfquery in that application without a datasource tag will use the application.datasource. Very cool.

Why do I have to set all of these properties? Can’t ColdFusion just look at the database and create an ORM object?

Yes it can. If you leave your CFC blank, ColdFusion will just map the table that you are pointing to, no questions asked. However, if you want to set any properties manually, you’ll have to set them all. So it’s good for simple prototyping, but if you need to do something more complex, you have to do the work yourself.

Why doesn’t ORM return ColdFusion queries?

Objects and tables don’t always match up. Queries are really good for exposing the results of a Select statement, but they aren’t designed to handle complex sets of data. (Which is different from saying they cannot handle results of complex SQL Select statements, because they can.)

Sometimes you’ve got complex relationships; sometimes you have tables that are set up for one purpose, but used for another; and sometimes you have multiple tables that really should be one object. Queries can certainly accommodate this, but ORM can often do it in a way that makes you more productive. What would be multiple queries that you have to manage and loop through to display using queries, becomes one object in ORM.

Now add to it that you can add business logic to these objects, things like calculations, display formatting, and combined properties… and ORM shows itself to be much more valuable than just another way of handling data.

Okay, and let’s say you REEEAAAAALLLLY want a query. Okay, you can run a function named EntityToQuery that will convert the results of an ORM operation to a query. (Provided that it’s a simple object, with no relationships or other funny business.) (Not valid in Australia, for people named Mark, with or without marsupial pouches.)

Where can I find out more about ORM in ColdFusion 9?

There are a few good blog posts and articles on the subject:

• Ben Forta’s ORM – Rethinking ColdFusion Database Integration
• Mark Mandel’s Introducing ORM in Adobe ColdFusion 9 beta
• What ColdFusion 9’s ORM means for your development

I’ll try to add them as I see them.