Just When I thought the RoR Discussion had Cooled...
Posted on Jul 21, 2006
...here it goes again. Well its not all specific to Ruby on Rails exactly, but to Ruby, Rails and some of the underlying concepts like scaffolds and object-relational mapping (ORM). In just the past few days, we have had a brief discussion of incorporating Rails-like functionality into Mach II on the mailing list, Sean's Ruby (sans rails) and ColdFusion comparison, Ted Neward's long-winded explanation of why ORM is the "Vietnam of Computer Science," and now Joe Rinehart's lengthy and detailed explanation of why he doesn't like Rails. In all cases here, the opinions are coming from experts whom I respect and who probably know more about this than I do, but I'd like to share my view nonetheless.I briefly toyed with Ruby and Rails many months back...anyone who saw the demos typically was initially impressed. When I played with the actual language and framework, the glow quickly wore off. I didn't get as detailed in my dislike as Joe (or spend as much time with it), but it just didn't feel comfortable. To me it felt like working in Microsoft Word. How so? Well, frequently when working in Word I am typing and Word thinks based upon what I typed that I want this section formatted in such and such a manner. More often than not it takes quite a bit of effort to tell Word to stop thinking for me and leave my text alone...if I want your help I will ask for it ok? In this manner, I agree with Joe's criticism of Rails which he described as Rails configuration is actually spread around in the source code. Basically all that configuration tends to acheive the ends of telling Rails to do what I want it to do and not what it thinks I should do. (Now, perhaps there is something in that...I mean alot of people love Word's autoformatting...so, all I am saying is I don't personally like my framework to think for me).
However, Joe focused alot on comparing Reactor (and to a lesser extent Model-Glue: Unity) to RoR. Many of the comparisons seemed to deal with ways in which Reactor and RoR handle object-relational mapping and active record. ORM is the focus of Ted Neward's polemic "The Vietnam of Computer Science." While I think his post suffers heavily from trying to hard to justify what seems like an off-handed remark he once made, it does make some interesting points which echo some of my recent thoughts on ORM. (Unless you are really intested, skip his whole Vietnam War synopsis in his post and get to the meat of the argument). He also gives a good overview of approaches to ORM (granted this is all from a Java perspective but relavent nonetheless).
The core of Ted's argument is that ORM suffers from a law of diminishing returns that are brought about by a flaw in the underlying assumption that you can automatically relate objects to relational data storage. He goes into some detail about the specific problems he sees. However, in my own experience, I have recently moved away from relying on ORM (in my case I was using Reactor - and this isn't intended to be a criticism of Reactor per se, I still see why so many people think it is a great resource). I found, personally, that my Gateways were still handcoded because the default methods will rarely meet any of your application's specific needs. So, in the end ORM was saving my having to write CRUD that I could easily auto-generate myself. Essentially, I did eventually start to feel, like Ted describes, that I was starting to put as much effort into making ORM work for me than it was saving me.
Now, I cannot speak for other CF ORM frameworks, but Reactor creates beans that follow an active record pattern, so I can do bean.save() or bean.load() or something like bean.getRelatedItems() (these are not necessarily the real methods...just for explanation purposes). At first this seemed both simple and powerful. However, for reasons I will not get into, I had to pull Reactor out of a project, and this excercise shows you how tied to a specific implementation your code becomes. I was left with two choices, recreate much of what Reactor did behind the scenes or rewrite most of my pages. In the end I went back and redid much of the application...not fun.
Ok, in defense of Reactor and ORM, I think it can have its uses. I mean the fact that I chose to rewrite alot of the pages was in large part due to the fact that Reactor offers alot of functionality right out of the box...many of which I missed having in my application. I am really not trying pick on Reactor, and I still find ORM an interesting concept and will continue to follow it. However, in the end, I see much of this as a matter of personal preference and doing things in a way that makes you feel most comfortable.
I personally like the idea of just generating generic beans, DAOs, Gateways (even services) as a starting point with the underlying assumption that they will always require some level of human intervention - that my database tables do not directly represent objects and that translating between what works in a relational database and an object requires some finessing. Speaking of which, I am tweaking a simple code generator I wrote a while back (that worked fine but generated horrid code unfortunately) and hope to share that with everyone when I am more confident in the results it produces.
Comments
Posted By Sean Corfield / Posted on 07/22/2006 at 12:21 PM
If all it's doing is saving me development time, I don't have the time to spend to save (?)
But if the argument is that it makes for a better system, then you have my ear.
For instance, with ORM you can modularize and therefore include unit testing.
Posted By Phillip Senn / Posted on 05/10/2007 at 7:48 PM