I Don't Care What An ORM Is!
Posted At : November 3, 2008 11:49 PM | Posted By : Bob Silverberg
Related Categories: OO Design, ColdFusion, Transfer
There have been some postings recently about the state of the ORM landscape in ColdFusion, and while I have found this conversation interesting, I have not found it particularly useful.
There exists a group of ColdFusion developers, myself included, who would like to improve the way that we write and structure our code. We have been encouraged to adopt a more object oriented approach to our development, and I, for one, have found it to be of great benefit.
One of the things that has made this transition easier for me is the existence of these "ORMs" for ColdFusion. I started off with Reactor, and now use Transfer, and I have found that not only do these "ORMs" do a lot of the more menial tasks for me, but they also encourage me to "think in objects". Sure, the objects that I'm working with are closely tied to the physical database structure, but they're still objects. I still get the benefit of encapsulation, and through the use of Transfer decorators I feel that I am able to give my objects meaningful behaviour, thereby creating rich business objects.
I know from experience that when a developer is starting down this path it can be quite daunting, and we often look to those with more experience than ourselves for guidance. I hope that someone in that boat would not be "turned off" the existing set of "ORMs" for ColdFusion because they are not considered to be true ORMs.
This brings me to the title of this post, which was inspired by a post by Peter Bell. I find Transfer to be an indispensable tool for building OO-like applications with ColdFusion, and can only encourage people to investigate and use it. It may not be a true ORM, but that doesn't make it any less useful. Let's not throw the baby out with the bath water.
I liked this comment by Isaac Dealy on his first post on the subject:
"I actually don't care for that as a definition of "ORM" because as a definition, it depends on an idea that's not expressed in the acronym. None of the individual words (Object, relational, mapping) actually express anything at all about when or where or how the mapping is accomplished, or whether or not the business model is aware of the mapping."
I think Isaac is right in implying that the definition of an "ORM" can be open to interpretation. If you're going to use Java's Hibernate as the standard against which to define whether other frameworks are ORMs, then yeah -- Joe makes some good points. But this reminds me of when people were debating whether the way DAOs and Gateways were written in CF were "true" DAOs and Gateways.
There's a fallacy in looking at OO concepts in ColdFusion through Java-tinted glasses. Maybe Transfer, Reactor, and Datafaucet aren't "true" ORMs in the Java sense, but maybe they can be classified as "ColdFusion ORMs".
In the end, though, who the hell cares what they're called? There's no doubt that these frameworks have been very useful to CF developers using OO concepts in their code. I'll call them "Larry" if it makes people happy.
Along these same lines, I also find some people's zealotry about writing "pure OO" (and avoiding thinking about the database like the plague) interesting from a purely academic standpoint, but not very practical since the vast majority of apps written by MOST CF developers are, in the end, datacentric and don't really call for true business objects with very complex behaviors.
First, thanks for your thoughts. It's really cool that we can discuss this w/o a flame war.
Bob, I completely agree that the persistence frameworks for CF have helped many transition to OO. It's helped me reinforce what I know about OO. My point was never to turn anyone off of them, and I wouldn't want my posts to do so...I make no bones about their benefits, saying that using one "saves many people much time" and that their development comes from a "pragmatic approach that opens up powerful new concepts to a larger development audiences." I'm definitely not encouraging tossing the baby out with the bathwater.
However, it's important that people know that the two (CF persistence frameworks and ORM technology) are not equivalent. There's a lot to ORM that's not covered by the CF frameworks, and I think it's important for people to know it exists, even if it's not necessary in our day to day work. Knowing more about ORM can explain many parts of why Transfer and Reactor work the way they do.
Tony, Hibernate isn't my standard for what makes something an ORM. My standard is simply the definition of ORM technology: something that I can use to map the differences between an object model and a relational database, and nothing written in ColdFusion can do that. That's not zealoutry - that's just asking something to meet its own claims. I've long taken the standpoint that CF should not be Java, going to far as to say "Get over it: CF isn't java" (http://www.firemoss.com/post.cfm/ColdFusion--Do-we...) at a time when many people were demanding interfaces.
I rolled my own Database abstraction layer and it saves me tons of time. Is is a true ORM? Not by a long shot.
All I have to do create CFC's for my database with a code generator (Illudium), load them into the application scope. I have a generic CFC to interface with the CFC's.
http://mgt.pastebin.com/f9702565
Now all I need to do for simple CRUD functions is call one function.
<cfset MyQ = Application.databaseService.runmethod("(Upsert/Select/Delete","Mytable", Mystruct, [mypk])>
That is it.
I don't care if it is a *true ORM*. My workload has just been reduced by two thirds. That is what matters. That is why I used CF in the first place.
I actually see Joe's point. He isn't arguing that you should use there persistence frameworks, just that it can be helpful to see the difference between them and a true ORM framework.
I have tried to be careful with my own data access layer (DataMgr) in pointing out that while it fills the same space as Transfer/Reactor/DataFaucet, it isn't an ORM.
It actually has a similar syntax to what you describe.
I see where you're coming from and admittedly you have tons more experience than I do in the Java realm. But I guess we just differ in how stringently we define an ORM. It's just like when people were saying that Gateways that CF developers are writing aren't "true Gateways" in the J2EE sense of the word:
http://www.remotesynthesis.com/post.cfm/What-the-H...
But I'll still call them Gateways, because it's become a ColdFusion convention, in a way. But really, in the end, they're just names. Although I noticed that you were trying to make clear that you weren't trying to discredit any of the CF "ORMs" out there in any way, it still came off to some people (like Bob) that you were. I take it your original blog post was academic/educational in nature (or maybe a call out to the CF community for someone to put out a "real" ORM? -- maybe not with CF9/Hibernate around the corner)
Also, I didn't count you among the "zealots". I was more referring to the Hal Helms school of thought, which avoids the use of ANY of the current CF ORMs because they don't fit into the OO ideal of the non-existence of the database. While Hal is great and I've learned a lot from his philosophies, in the end a lot of the apps that I end up writing are ALL ABOUT the data.
That said, my reading of Joes posting was that he ALSO sees value in db abstraction frameworks.
To me he was just making a useful distinction between ORMs and the db abstraction frameworks we have in CF. I don't think he was saying either was right or wrong.