今天起春節希望每天介紹 Rails4 Patterns 內的一個章節給大家,這是一個在 Code School 的課程,原址:https://www.codeschool.com/courses/rails-4-patterns

肥肥的 Controller 是不好的

原因有幾個:

  • 會難以理解
  • 商業邏輯難以統整
  • 程式碼間容易衝突
  • 難以開發新功能

像是以下程式碼

class ItemsController < ApplicationController
  def publish
    if @item.is_approved?
      @item.published_on = Time.now

      if @item.save
        flash[:notice] = "Your item published!"
      else
        flash[:notice] = "There was an error."
      end
    else
      flash[:notice] = "There was an error."
    end

    redirect_to @item
  end
end

當時間的推進,應用的發展,條件式只會越來越複雜

if @item.is_approved? # 原先的條件式
# ->
if @item.is_approved? && @iterm.user != "Loblaw" # 新增條件

這裡切記一個原則:「Tell, Don't Ask」,應該要直接的告訴物件它要做什麼事情。而不是透過問句的方式去確認目前它的狀態是什麼後,再決定作什麼事情。

商業邏輯該丟到 Models 內

如剛剛的 controller,我們可以將邏輯性的功能包裝丟至 model 內,那對 controller 而言就可以符合 Tell, Don't Ask 原則。

# app/controllers/items_controller.rb
class ItemsController < ApplicationController
  def publish
    if @item.publish # 明確知道這邊的動作是將 item 發佈
      flash[:notice] = "Your item published!"
    else
      flash[:notice] = "There was an error."
    end

    redirect_to @item
  end
end
# app/models/item.rb
class Item < ActiveRecord::Base
   belongs_to :user

   def publish
     if !is_approved? || user == 'Loblaw'
       return false
     end

     self.published_on = Time.now
     self.save
   end
end

函式為確保是簡潔與可讀性的程式碼,特別將 if-else 的邏輯單純化,如果一個 if 就能乾淨俐落,為什麼還要來個 else,大家都愛直線,不要拐彎抹角阿!

所以這邊才會是

if !is_approved? || user == 'Loblaw'
  return false
end
...

而非

# wrong case
if is_approved? || user != 'Loblaw'
  ...
else
  return false
end

避免在 Callbacks 中呼叫其他功用的物件

因為 callback 本身就像是一個物件生命週期的一個環節,如果牽扯到其他的物件,不只讓人在看程式碼會覺得有點跳,甚至因為交流密切,間接影響到物件的資料庫運作週期。

class User < ActiveRecord::Base
  before_create :set_token

  protected
    def set_token
      self.token = TokenGenerator.create(self) # another class object
  end
end

為此建立一個客製化的函式

# app/models/user.rb
class User < ActiveRecord::Base
  def register # 另外拉一個函式,專作註冊
    self.token = TokenGenerator.create(self)
    save
  end
end

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def create
    @user = User.new(user_params)
    if @user.register # 使用客製化的函式
      redirect_to @user, notice: 'Success'
    else
      ...
    end
  end
end

Callbacks 應該是用來作為更改欄位值或其他內在因素為主

# app/models/user.rb
class User < ActiveRecord::Base
  before_create :set_name

  protected
    def set_name
      self.name = self.login.capitalize if name.blank?
    end
end

也要特別留意,callbacks 放在 protected 內是 Rails 的 Convention,務必要遵守

不是所有的 Models 都一定要是 ActiveRecord

以被檢舉的使用者需要的停權動作為例,裡面牽扯到許多要考慮的層面,例如停權後就不能發言、不能登入等等

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def suspend
    @user = User.find(params[:id])
    @user.suspend!

    redirect_to @user, notice: 'Successfully suspended.'
  end
end

# app/models/user.rb
class User < ActiveRecord::Base
  has_many :items
  has_many :reviews

  def suspend!
    self.class.transaction do # transaction 包起來可以讓這些動作對於資料庫來說只是一件事情
      self.update!(is_approved: false)
      self.items.each { |item| item.update!(is_approved: false) }
      self.reviews.each { |review| review.update!(is_approved: false) }
    end
  end
end

以上例來說,問題是同個函式內包含太多的邏輯

同個 class 裡面太多邏輯,可以拆成各自負責的工作。也要注意函式牽扯到太多其他的物件,可能會導致「God Object」現象發生,就是指作太多事情的意思。

class User < ActiveRecord::Base
  ...
  def suspend!
    self.class.transaction do
      disapprove_user!
      disapprove_items!
      disapprove_reviews!
    end
  end

  def disapprove_user!
  def disapprove_items!
  def disapprove_reviews!
end

抽象化:不是所有跟使用者有關係就得都在使用者的 Model 內

以停權使用者這件事情來說,抽象化有幾個好處:

  • PORO: Plain Old Ruby Object
  • 只需一個正規的 instance method
  • 這個類別就只需要專注一件事情就好
# app/models/user_suspension.rb
class UserSuspension
  def initialize(user)
    @user = user
  end

  def create!
    @user.class.transaction do
      disapprove_user!
      disapprove_items!
      disapprove_reviews!
    end
  end

  private
    def disapprove_user!
    def disapprove_items!
    def disapprove_reviews!
end

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def suspend
    @user = User.find(params[:id])
    suspension = UserSuspension.new(@user)
    suspension.create!

    redirect_to @user, notice: 'Successfully suspended.'
  end
end

其他常見的抽象化:

  • UserRegistration
  • PlanSubscription
  • CreditCardCharge
  • ShoppingCart

小結一下,所以常會使用非 ActiveRecord 的方式將獨立且唯一的商業邏輯搬出來成一個新的類別。