Rails Best Practices

Move finder to named_scope

Complex finders in controller make application hard to maintain. Move them into the model as named_scope can make the controller simple and the complex find logics are all in models.

Use model association

Use model association to avoid assigning reference in controller.

Use scope access

You can use scope access to avoid checking the permission by comparing the owner of object with current_user in controller.

Add model virtual attribute

Do not assign the model's attributes directly in controller. Add model virtual attribute to move the assignment to model.

Use model callback

Use model callback can avoid writing some logic codes in controller before or after creating, updating and destroying a model.

Replace Complex Creation with Factory Method

Sometimes you will build a complex model with params, current_user and other logics in controller, but it makes your controller too big, you should move them into model with a factory method

Move Model Logic into the Model

In MVC model, controller should be simple, the business logic is model's responsibility. So we should move logic from controller into the model.

model.collection_model_ids (many-to-many)

When you want to associate a model to many association models by checkbox on view, you should take advantage of model.collection_model_ids to reduce the code in controller.

Nested Model Forms

Use accepts_nested_attributes_for to make nested model forms much easier, this feature is provided by rails 2.3

Overuse route customizations

According to Roy Fielding’s doctoral thesis, we should use restful routes to represent the resource and its state. Use the default 9 actions without overusing route customizations.

Needless deep nesting

Some people will define 3 or more level nested routes, it's a kind of over design and not recommended.

Not use default route if you use RESTful design

If you use RESTful design, you should NOT use default route. It will cause a security problem. I explain at http://ihower.tw/blog/archives/3265 too.

Keep Finders on Their Own Model

According to the decoupling principle, model should do finders by itself, a model should not know too much about associations finders logic.

Love named_scope

named_scope is awesome, it makes your codes much more readable, you can also combine named_scope finders to do complex finders.

the Law of Demeter

According to the law of demeter, a model should only talk to its immediate association, don't talk to the association's association and association's property, it is a case of loose coupling.

DRY: Metaprogramming

If you find some methods whose definitions are similar, only different by the method name, it may use meta programming to simplify the things.

Extract into Module

Some codes in your model are related, they are take charge of the same things, such as logging and authorization. We can extract these codes into a module to reuse them.

Extract to composed class

If a model has some related columns, e.g. a user has an address_city and an address_street, you can extract these properties into a composed class.

Use Observer

Observer serves as a connection point between models and some other subsystem whose functionality is used by some of other classes, such as email notification. It is loose coupling in contract with model callback.

Isolating Seed Data

Rails 2.3.4 provides db:seed task that is the best way to insert seed data for set up a new application.

Always add DB index

Always add index for foreign key, columns that need to be sorted, lookup fields and columns that are used in a GROUP BY. This can improve the performance for sql query. If you're not sure which column need to index , I recommend to use http://github.com/eladmeidar/rails_indexes, which provide rake tasks to find missing indexes.

Use before_filter

Don't repeat yourself in controller, use before_filter to avoid duplicated codes.

DRY Controller (and debate)

For CRUD resources, we always write the same 7 actions with duplicated codes. To avoid this, you can use inherited_resources plugin. But be careful, there is DRY controller debate!! (http://www.binarylogic.com/2009/10/06/discontinuing-resourcelogic/) 1. You lose intent and readability 2. Deviating from standards makes it harder to work with other programmers 3. Upgrading rails trouble

Move code into controller

According to MVC architecture, there should not be logic codes in view, in this practice, I will introduce you to move codes into controller.

Move code into model

According to MVC architecture, there should not be logic codes in view, in this practice, I will introduce you to move codes into model.

Move code into helper

According to MVC architecture, there should not be logic codes in view, in this practice, I will introduce you to move codes into helper.

Replace instance variable with local variable

In partial view, we can use the instance variable directly, but it may be confused and make it hard to reuse anywhere, because we don't know exactly which instance variable can be used, so use the local variable in partial with explicitly assignment.

Fix N+1 Queries

N+1 Queries is a serious database performance problem. Be careful of that situation! If you're not sure, I recommend you install http://github.com/flyerhzm/bullet plugin, which helps you reduce the number of queries with alerts (and growl).