Ruby on Rails ORM through ActiveRecord

Rails offers an ORM layer.  This layer is not a very strict layer.  To filter or sort objects, you are actually writing SQL code.  There doesn’t seem to be much complaining in the community about this mis-feature.  In fact in the Agile Web Development with Rails book, the author basically makes snide comments about people who think that the object hierarchy and the database model should not be tied tightly together.  This may just be a cultural thing.  Ruby on Rails seems to be used mostly on brand new projects.  Given this situation, it is understandable why Rails developers don’t understand the importance of uncoupling the database from the object graph.

One of my first consulting jobs was with AMC Theaters.  I was on a tiny project that needed to read from a database that we had absolutely no control over.  Unfortunately for us, the tables and fields often had entirely different purposes than what they were labeled as.  These corporate databases can last decades and changing them is not possible.  Many different groups have written code around these names and changing a field in a table has ramifications way beyond our little group.  It would cause applications to break and there is no funding to fix all the applications just because we don’t like the field name.  Consequently, you are left with the task of mapping a field in a table that has a non-sense name to a field in the object that actually makes sense when you read the code.  This is where Ruby fails to deliver with it’s implementation of ORM through ActiveRecord.

Since I’m learning Rails so I can create new ideas quickly, I will happily use the current ORM.  But this is one area where Rails needs to improve.