Company.all(:include => :products,  :conditions => “products.id IS NOT NULL AND products.weight > 10″)

其实写这个查询的人的目的是为了找出拥有products，并且products的weight大于10的company。但这个语句导致的sql查询是性能低下的：

SELECT companies.id AS t0_r0, …., products.id as t1_r0, … FROM companies
LEFT OUTER JOIN products ON products.company_id = companies.id
WHERE products.id IS NOT NULL AND products.weight > 10

这个sql查询有两个问题：

• 结果集中的products信息是不需要的
• LEFT OUTER JOIN的性能劣于INNER JOIN

我们可以使用如下的语句来避免这两个问题：

Company.all(:joins=> “INNER JOIN products ON products.company_id = companies.id“, :conditions => “products.weight > 10“)

它生成的sql是：

SELECT companies.* FROM companies
INNER JOIN products ON products.company_id = companies.id
WHERE products.weight > 10

这个查询的效率会高很多。所以，正确使用Rails的finder是至关重要的。

Rails之美

简洁

Rails是基于ruby语言的。动态语言带来的好处之一是代码量的急剧减少。有一个鲜活的例子，有一次跟客户进行pair，把曾经用Java实现的一个900多行的类，缩减到了100行。客户很是惊讶。当然，纯粹量的减少可能并不代表什么，但至少带来了清晰和易读这两个对代码来说非常重要的特性。

因为动态语言的良好支持，Rails框架使重复的配置工作减少到了极致。比如在Java世界的大量OR Mapping配置文件，在Rails里面不再需要。虽然现在Java世界的配置量也在不断地精简，但还是占据了一定的工作量。重复工作的减少，亦即工作效率的提升。

作为Web开发领域的DSL，Rails提供的各种机制在各个层面极大地简化了开发的工作量和难度。比如ActionView提供的FormHelper，简化了页面上form的生成；比如ActiveRecord提供的Association，简化了模型之间关联的维护。

举个association的例子，来看一下Rails的简洁之处。下面这两个模型是一对多的关系：一个lightbox有很多images。

class Lightbox < ActiveRecord::Base   
end   
  
class Image < ActiveRecord::Base   
end

要删除一个lightbox，以及它的所有images，需要这样写：

@images = Image.find_by_lightbox_id(@lightbox.id)   
@images.each do |image|   
  image.destroy   
end   
  
@lightbox.destroy 

接下来，让我们给它们声明正确的关联关系：

class Lightbox < ActiveRecord::Base   
  has_many :images, :dependent => :destroy   
end   
  
class Image < ActiveRecord::Base   
  belongs_to :lightbox
end

则删除操作就变得简单了，且在语义和逻辑上更加明确和清晰：

@lightbox.destroy

DSL的一个目的是使某个领域的开发变得更加具体、简单和清晰。Rails框架是从一个现实项目中提炼出来的，这同时也证明了一句话：好的框架都不是凭空想象出来的。

Rails还有很多其它方面可以体现它的简单。简单，就是美。

透明

项目开发过程中，让我觉得很痛快的一件事情是：基本上不需要借助任何外部的文档。

因为Rails本身是透明的，这首先是动态语言提供的好处。当需要了解任何一个方法的功能或者实现时，只需要跳到那个方法查看源代码即可。

同时，对大多数方法，Rails都提供了详尽的文档以及具体的示例。

开放的源代码，以及详尽的注释，让开发人员得以在一个“透明的环境”上进行开发。开发中可以彻底地了解所用工具的习性，这不可谓不是一件痛快的事情。

自由

对一个问题，Rails往往都提供了多种解决方案。我们可以根据问题的场景，自由地选择合适的方案。

比如对于页面中form的生成，我们可以选择使用form_tag方法。但当这个form跟对象关联的时候，更好的选择是使用form_for方法。结合text_field等helper方法，使页面上的元素跟对象的属性更加紧密地结合。

下面再举一个association的例子，来看看Rails如何表现自由的精神。声明多对多关系时，一般是这样的：

class Teacher  
  has_and_belongs_to_many :students  
end  
  
class Student  
  has_and_belongs_to_many :teachers  
end 

但有时我们需要利用中间表，并让它映射到一个模型。那么，可以这样来声明模型之间多对多的关联：

class Teacher  
  has_many :relations  
  has_many :students, :through => :relations  
end  
  
class Relation  
  belongs_to :teacher  
  belongs_to :student  
end  
  
class Student  
  has_many :relations  
  has_many :teachers, :through => :relations  
end 

选择的多样化带来的是自由。但根据需要和场合选择正确的方案，更加重要。

开放

Rails所体现的一点极其重要的精神是：开放。因为Rails从来不限制你去做任何事情。

有个项目是建立在一个遗留数据库上，并且大多数数据库表结构和遗留数据因为有些原因不能更改。但问题是表结构并不满足Rails的约定，下面列举一些问题和解决办法来窥探一下Rails的开放精神所在。

问题1：单数表名

根据Rails的约定，表名都是复数形式的。比如一个User模型，对应的表名是users。而遗留数据库上的表名是单数形式：user。

解决方案

在environment.rb文件的配置初始化里，关闭默认的复数表名配置：

config.active_record.pluralize_table_names = false

问题2：type字段不代表单表继承

根据Rails的约定，type字段是单表继承的保留字段。当从数据库读取数据并实例化成对象时，它会根据type字段的内容来寻找相应的子类型。但这里type字段并不代表单表继承。

解决方案

在模型里面声明另一个字段代表单表继承，比如：

set_inheritance_column :clazz

问题3：type字段的值不满足单表继承的约定

又出现另一个问题，type字段用来表示单表继承，但是它的值并不满足单表继承的约定。根据Rails的约定，type的值应该是类名。比如ShoppingCart继承自ImageCollection，那么type的值应该是”ShoppingCart”。但在遗留数据库里，使用的是”shopping_cart”。

解决方案

这里涉及到两个问题，一是在存储一个对象时要设置正确的type值，二是实例化成对象时，需要根据type值找到正确的子类型。通过查看源代码，发现计算type值和子类型的分别是ActiveRecord上的sti_name和computer_type方法。大家都应该想到了解决方法，就是覆盖这两个方法。对于ShoppingCart类，解决方案可以这样：

def sti_name
  super.underscore.upcase
end

def compute_type(type_name)
  super(type_name.downcase.camelize)
end

通过上面的例子，我们已经了解了Rails的开放。Rails有很多约定，但不代表强制。而且Rails的开放不仅限于此，比如你可以打开任何一个类，往里面添加方法（当然，这是Ruby给予的权力）。举个例子，比如我们可以通过打开NilClass，来实现Null Object模式（在有些情况下这种做法比较极端）:

NilClass.class_eval do
  def your_method
     …
  end
end

有些语言在天性上对程序员防备多于信任，他们总觉得赋予程序员过多的权力，会容易带来破坏。但其实防止破坏靠的应该是程序员的修炼和自我约束。语言，应该以一种更加开放的态度赋予程序员更多的权利和自由。

轻灵

很多人都觉得Rails是一个庞然大物。但其实Rails并不庞大，DHH在迷思系列里面也解释过。而且，Rails可以轻松剔除任一可选组件。比如要去除ActionController的benchmark组件，只要注释掉include ActionController::Benchmarking，并删除相应的文件即可。

在这背后，其实有一个神奇的方法，叫做alias_method_chain。这个方法非常有用，它的设计理念很好地支持了Rails轻灵的特性，因为它让Rails的各个可选组件都只是很“轻巧”地挂载在上面。继续用Benchmarking这个例子来了解一下它。

Benchmarking的功能是度量action的性能，并把结果输出到日志。这其实是对perform_action方法的增强。从Benchmarking源代码中可以看到如下的代码：

alias_method_chain :perform_action, :benchmark

以及perform_action_with_benchmark方法的实现。

其实，alias_method_chain跟下面的实现是等价的：

alias_method :perform_action_without_benchmark, :perform_action  # 为原来的方法建立别名
alias_method :perform_action, :perform_action_with_benchmark      # 重定向原来的方法名到功能增强之后的方法

这种方式其实就是AOP的工作方式：ActionController::Base声明了perform_action方法，但它对benchmarking一无所知，只要把Benchmarking模块包含进去，就获得了benchmark的功能。Rails通过这种方式实现了低耦合，我们可以轻松地选择去除非必要的所有可选组件。Rails并非庞大，它是轻灵的，但我们需要了解它。

发展到今天，Ruby和Rails社区已经非常的活跃和强大。千万开源爱好者在不停地贡献着各种各样的Rails插件和Ruby库。

比如认证系统插件：restful_authentication，分页插件：will_paginate等等，这些插件的出现帮助我们节省了很多工作。并且，这些插件的实现都非常的优美，并不断地在优化和演进。

强大的社区支持，丰富的插件，让Rails开发变得更加容易。

优美

Rails的优美体现在很多地方，比如它本身就是一个REST风格的WEB架构。

但REST就代表着优美么？这不足以让人信服，还是举个例子吧。

假定有一个InvoicesController，现在需要生成一个invoice的pdf。我们可能会想到给controller添加一个叫做download_pdf的action：

def download_pdf
  invoice = Invoice.find(params[:id])
  send_data(generate_pdf(invoice), :filename =>