The child who receives a hammer for Christmas will discover that everything needs pounding – Gerald Weinberg

Fred George’s keynote at “Rails Underground” was titled “Rails is an hammer”. It was along the “grumpy old developer” line that kids today jump to use all these fancy frameworks without considering whether they are appropriate to the job in hand. It’s a fun spiel, and one I’ve levelled against a lot of Java frameworks and libraries. Is Rails really inappropriate for most web applications? No, but it’s worth asking the question.

The main charges against Rails are:

• it does not have a domain layer
• the models are based on relational database tables rather than object design

Does Rails not have a domain model?

This is good point that is not often made. Having MVC not the same as a layered architecture. As Jay Fields “discovered” that his Presenter Pattern was not sufficient for some applications it was Domain Driven Design his team turned to concepts such as Services and Repositories. Nowhere does Rails mandate that ActiveRecord models should be accessed directly by controllers.

Good domain models are tough. It can take a long time working with an application before the right model is discovered. Leaping to a model too early – premature abstraction – often leads to an inappropriate object architecture that it can be difficult to write your way out of and Byzantine back channels are needed for operations that do not fit the original design.

Something that Rails has taught me is how far you can go with just MVC and a good framework. I wouldn’t say this for a typical Java web app, but you ain’t gonna need a layered architecture. Until you do need one. Then won’t be a big deal to refactor towards that, as long as you keep you’ve kept your code clean, DRY, and well-tested.

Are Rails ‘models’ are based on database tables?

This came up in the Scotland on Rails CouchDB controversy, and I dispute that Rails ActiveRecord models represent rows in relational database tables. It’s the other way round: relational databases happen to be the persistence mechanism for ActiveRecord; the database is subservient to the object model. No-one normalises their Rails database; you might fret about keeping your objects DRY and separation of concerns but I doubt you look at your Rails DB worry about repeating attributes. It’s about associations, not relations and join tables.

Admittedly, right now Rails is strongly bound to being back by a RDBMS, and there are some hoops to jump through if you want to use something else. That does not stop a growing number of people using alternatives like CouchDB. The promise of Rails 3 is that it will become trivial to swap in alternative Object Persistence mechanisms, so this will become less of an issue.

Given up on Rails yet?

Fred had some valid points, and it was fun to see how far he could get with vanilla Ruby, Sinatra, and persisting straight to disk. I’m still going to be reaching for Rails to solve most of my web app problems, though. After all it’s a pretty versatile hammer, and there’s a lot of things that need pounding out there.