Concern 的差異

2019-07-30

Ruby on Rails

Refactor

專案到中後期長大時通常會開始整理 fat model，但 code 到底要怎麼重構才會比較好呢？

Refactor 時基本目標

解耦
易於測試

Service Object

Service Object 是一個純粹的 Ruby Object，又稱為 PORO(Plain Old Ruby Object)，簡單且沒有任何繼承關係的純 Ruby 物件，這樣一來也不用擔心繼承了什麼帶來的 side effect

這是很常見的整理手法，通常還會依照不同需求有各種 pattern

Form object
Null object
Query object

而 service 是一個比較中庸的統稱，也就是說，當你發現一個運算邏輯他可能有跨 model 的操作，例如流程控制是屬於商業邏輯的部分，並不是單純操作資料，那麼他就可以被抽出來做 service 而隔離直接繼承 ActiveRecord

抽 service object 幾個要點

邏輯複雜
牽扯到多 model，無法特別歸類於特定 model
會呼叫外部服務，例如發送至 slack
與核心邏輯無關，例如定時生成報表
可能重複使用

基本約定

每個 service object 只做一件事
Instance 只有 2 個 public API, 通常是 initialize 和 perform(要換成 execute / call 都行)
Class method 只有 1 個 public API
回傳值盡可能只有 true / false（定義好就好，盡量單純）

每個團隊可以自行調整這樣的 convention

我比較常用的習慣

class SendSmsService
  attr_reader :errors
  
  def initialize(phone, country)
    @phone, @country = phone, country
    @errors = []
  end
  
  def perform
    # do something
    
    errors.blank?
  end
  
  private
  
  # your private method
end

在其他地方可以這樣呼叫

service = SendSmsService.new("012343455", "zh_TW")

if service.perform
  # redirect to somewhere
else
  # show error message
  flash[:alert] = service.errors.join(", ")
  # redirect to somewhere
end

並且能將錯誤訊息從 errors 拿出來，測試也變得更易於測試

所以說， Service Object 沒有一個絕對固定的型態，他基本上就是業務邏輯的抽象封裝。

Library

通常會放在 /lib 之下的檔案，基本上會是能夠跨 project 共用，甚至可以直接包成 gem 給大家使用的。

例如 GoogleApi、FacebookAuth 之類的

Concern

Concern 是加強版的 mix-in，方便整合不同區塊的程式碼，將一些部分簡單的功能抽出來，可以在多個 model 共用

例如可能有 User / Manager 都要用到 add_role

module RoleManagable
  extend ActiveSupport::Concern

  def add_role!
    # do something
  end
  
  def remove_role!
    # do something
  end
end

然後在 User model 內使用

class User < ApplicationRecord
  include RoleManagable
end

Nic Lin's Blog

[Rails] Service / Library / Concern 的差異

Service Object

Library

Concern

參考來源