ColdFusion and Transfer (And that 3 letter "O" word)

This post is more than 2 years old.

It's been an interesting few days (in the blogs at least) in terms of ORMs and ColdFusion. A few days ago Jason blogged about a MAX session involving ColdFusion 9 and ORMs. Then today Joe Rinehart posted a great article on the current state of ColdFusion and ORMs: Does ColdFusion have no real ORM frameworks? This was followed up by another: What makes a framework an ORM? (I'll also point out Brian's take as well: Joe Rinehart Stirs the Object-Relational Mapping (ORM) Frameworks Pot)

Joe's article is pretty darn good, and drives home the real benefits an ORM framework can provide. I can personally attest to this seeing that we use Hibernate at work. Nothing is cooler than dropping all your tables as a quick way to get rid of bad data. Why can I drop all my tables? Because Hibernate will take care of recreating everything it needs.

Since the release of Transfer 1.1, I've been waiting to find the time to really dig into Transfer. While I agree with Joe's arguments that we don't have a real ORM framework in ColdFusion, at the same time (and both Joe and Brian agree here), there is some real darn good benefits to using Transfer within ColdFusion.

So with that in mind I'm launching a simple series of articles that will serve as a basic tutorial of Transfer 1.1. I hope this will be useful for others, and for me as well since I never felt like I got a good formal grounding in Transfer. Even just perusing the Transfer Overview I was surprised by some of what Transfer offered. This will hopefully be a good learning experience for everyone. If things work out right, I can wrap this before MAX and we can compare and contrast Transfer to what CF9 will offer.

The application I have in mind is a simple employee directory. Nothing earth shattering, but I've got the first build ready for my blog entry tomorrow and I think it works good for the first draft.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Anthony Webb posted on 11/4/2008 at 9:23 AM

Looking forward to this one Ray, an ORM skeptic myself (I love the flexibility that writing my own code affords me, can an ORM really do EVERYTHING?) That said, I'm willing to keep an open mind.

Comment 2 by Akbarsait posted on 11/4/2008 at 12:09 PM

I just started using Transfer in projects and looking forward your Transfer blog post series to learn more about it.

Comment 3 by Mark Mandel posted on 11/4/2008 at 1:57 PM

@Anthony -
An ORM isn't about doing * everything * for you.

It's about doing some of the menial tasks that can be automated by framework based code, so you don't have to do it.

An ORM isn't going to replace [insert favourite database specific feature here], because it can't, and also, it probably shouldn't, but it will allow you to automate your CRUD, and usually a lot more as well.

If uses appropriately and in the right places its a great time saver.. if you try and shoe horn it into every single part of your application ;o) its going to make your head hurt.

Comment 4 by Gary Gilbert posted on 11/4/2008 at 3:00 PM

The more I work with Groovy and Grails the more spoiled I get it just handles so much of that mundane stuff so I can concentrate on more important things.

We have an Intern that started with us a couple of months ago who studied CompSci and had done 4 years of Java in University. I started him working on a Grails project and he has pretty much decided that this is how programming SHOULD be.

With a well writen ORM you still have flexibility, an ORM is an enabler, a good ORM doesn't restrict you from being flexable it enables you to be more productive and spend your energy on whats important by eliminating a lot of the mundane

Comment 5 by Chris H posted on 11/4/2008 at 6:29 PM

just started looking into Transfer as well, so i will follow your journey closely...

Comment 6 by Yves posted on 11/4/2008 at 8:16 PM

Can't wait to read the articles on Transfer. I haven't yet used it... but am interested in the possibilities.
;-)

Comment 7 by Henry Ho posted on 11/4/2008 at 11:54 PM

The biggest turn-off I have with Transfer is the overhead of specifying the Transfer.xml. Although the Illudium PU-36 Code Generator (http://cfcgenerator.riaforg... does help with some of the heavy-lifting, the relationships still needs to be specified in the XML myself because it couldn't pick out the PK/FK relationship from introspecting the DB.

Secondly, the business object created by Transfer is closely resemble of the table in SQL. Although additional behavior can be introduced by the decorator, sometimes the ideal object may not be anything like the structure of my DB tables. That's why my team and I couldn't justify of using Transfer for more complex web applications that we build.

Anyway, thanks Ray for doing so much for the CF community! Just a suggestion, maybe the last tutorial of your series can introduce how Model-Glue works with Transfer as well! :)

Comment 8 by Raymond Camden posted on 11/5/2008 at 12:26 AM

@HH: You bring up some good points. You do need to do some typing in the XML. I don't necessarily see this as a big deal per se. To me it's just defining my business object. If you read Joe's article on ORM, we can see that over in Hibernate it is a much less difficult.

Your issue with the TO (the CFC made by Transfer, the Transfer Object) is not something that has ever bothered me. I never felt like it was a simple reflection of my db row.