Rails creator has data modeling opinion

I just finished watching David Heinemeier Hansson's (DHH) speech and reviewing his slides from Rails Conf. 2006. This speech isn't just entertaining, its essential study material. In this article I've collected all my study aids: DHH's video, his slides, and my humble take away message.

So, if you haven't already done so, go ahead and watch DHH's video and follow along with his slides. The main point that I extracted is to keep your controllers simple. Do not add actions beyond CRUD (Create, Read, Update, and Delete). According to the prophecy, constraining your controller to these actions will bless you with an enriched model and a design perfect for Rail's new web services.

DHH has some great examples in his slides, but if you've decided to read along before you invest in watching the video ... well, I will oblige you with a less than perfect example of how constraining your controllers to CRUD provides a better model.

Let’s say that you’re creating an application that tracks "projects" and "employees" with a many-to-many relationship. A project has assigned employees, and employees may be assigned to multiple projects. Eventually you would add an action to your employee controller named something like "assignToProject". According to DHH, this breaks CRUD. The first symptom that you are breaking CRUD, besides creating a new action is the choice you’re forced to make ... 1. Do you create the action "addEmployee" to your project controller? or 2. Do you create the action "assignToProject" in your employee controller? Another symptom is the cringe you feel when you’re asked to track additional information about the relationship - such as when an employee was assigned to the project. This is where Rails got into the sticky mess of rich associations using the push_with_attribute method. Yuck! We don't have to live like this!

In our perfect world where we are free to model the prophecy, we would create another model that tracks not a Project, and not an Employee; but the relationship between the two. DHH says "Don't just model things". In this example we would create another model named "Assignment". Now we don't need an "assignToProject" in our employee controller nor an "addEmployee" to our project controller. We simply have a "create" action in our Assignment controller. Now that we've enriched our model, we can keep our controllers wonderfully simple. Added bonuses include the easy ability to track additional information about assignments - such as when did the assignment begin or even who authorized the assignment. This information can be easily stored in the assignment model without fear of someone suggesting it should reside in either the project or employee model where it definitely does not belong.

One problem DHH mentions is that CRUD needs a better name. I liked Alex Bunardzic suggestion for RIDE (Read, Insert, Delete, Edit). On second thought, maybe CRUD doesn't need a new hyped up name. Maybe its just a healthy revisit of classic computer science.

And a problem that I will save for another post ... consider a new bad temptation -- now that having an action besides CRUD in my controller means re-thinking my model ... I'm afraid I'm going to start cramming functionality inside CRUD actions that don't really belong there. This would be bad. I'll have to work out these distinctions in a later post.

Posted by Jeffrey Hicks at 07:45 PM  Permalink

This is a public forum. CMP Media and its affiliates are not responsible for and do not control what is posted herein. CMP Media makes no warranties or guarantees concerning any advice dispensed by its staff members or readers.

Community standards in this comment area do not permit hate language, excessive profanity, or other patently offensive language. Please be aware that all information posted to this comment area becomes the property of CMP Media LLC and may be edited and republished in print or electronic format as outlined in CMP Media's Terms of Service.

Important Note: This comment area is NOT intended for commercial messages or solicitations of business.