Rails Tip: What goes where (directory structure) - A cheat sheet

I work with Rails on a pretty much daily basis in my day job. While I own Agile Development with Rails, am subscribed to the Rails mailing list, and read a number of blogs where the authors touch on Rails I've been slow to pick up some of the subtleties of using the framework.

A few coworkers also have all those resources available, but can't seem to wrap their heads around how the project is stuctured.

What Goes Where (or the Rails framework structure)

Rails defines a whole hierarchy of folders when you first generate a project. While some are very noticable in their intent, others can be confusing. Here's a simple breakdown of what goes where:

Rails Cheat Sheet (89.1 Kb)

While a lot of this should be simple and straightforward to pick up, I've found that I generally tend to get a little sloppy about my division of code between app/models, lib and vendor. Remember, if you didn't write it, it goes in vendor. If you wrote it and it doesn't derive from one of the big base classes of Rails (ActiveRecord, ActionMailer or Actioncontroller) it probably goes in lib - even if it is considered a "model" class. At least I like to try and follow that rule. Otherwise in complex apps you'll either end up with two undesirable results - you'll place tons of code in the controllers which could be encapsulated in lib models; or you'll end up putting all these custom models which have nothing to do with the Database in app/models and 'pollute' the folder - making it difficult to discern which models are DB abstractions and which are non-persistent.