はじめに

Ruby on RailsなどのMVCフレームワークで構築したWebシステムにはアンチパターンというものが存在します。システム開発におけるアンチパターンとは、避けるべき悪い設計や実装方法のことを指します。

MVCフレームワークでありがちなアンチパターンの一つとして「ファットコントローラー」があります。これは読んで字のごとく、コントローラーにいろいろな処理を詰め込んでしまった結果、コントローラーが肥大化してしまっている状態です。

ファットコントローラーを解消する手段として、コントローラー内の処理をモデルなどに移動する方法があります。しかし、それもいつかは限界が来て今度は「ファットモデル」という別のアンチパターンに陥る可能性が出てきます。

MVCフレームワークでは"Skinny Controllers, Fat Models"、つまり「痩せたコントローラー、太ったモデル」が推奨されています。コントローラーを太らせるよりモデルを太らせるほうがよいということです。

しかし、だからといって何千行、何万行もあるモデルでは全体の見通しが悪く、可読性・保守性が低いと言わざるを得ません。

そこで、MVCフレームワークでシステム開発を行う際には「デザインパターン」の設計が重要になってきます。コントローラーやモデルではない別のロジック層を用意し、処理を適切に分散することで可読性・保守性が向上します。

デザインパターンには多くのロジック層が存在します。この記事では「Service Object」について説明します。

Service Objectについて

概要

Service Objectとは、アプリケーションの中心となる処理を独立したクラスに集約するデザインパターンのことです。これを活用することで、以下のようなメリットが得られます。

コントローラーからビジネスロジックを分離できるので、コントローラーのコードが簡潔になり、責任範囲が明確になる
ビジネスロジックを再利用しやすくなるので、同じ処理を複数の場所で書く必要がなくなる
ビジネスロジックがService Objectに集約されているので、単体テストが容易になる

実装例

ユーザー登録処理を例にService Objectを実装してみます。

app/services/user_registration_service.rb

class UserRegistrationService
  def initialize(params)
    @params = params
  end

  def call
    user = User.new(@params)
    if user.save
      # 成功時の処理
    else
      # 失敗時の処理
    end
  end
end

app/controllers/users_controller.rb

class UsersController < ApplicationController
  def create
    service = UserRegistrationService.new(user_params)
    service.call
  end

  private

  def user_params
    params.require(:user).permit(:name, :email, :password)
  end
end