はじめに

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

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

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

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

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

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

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

Form Objectについて

概要

Form Objectとは、フォームに関連する処理を独立したクラスに集約するデザインパターンのことです。これを活用することで、以下のようなメリットが得られます。

コントローラーからフォームの処理を分離できるので、コントローラーのコードが簡潔になる
フォームの処理をテストしやすくなるので、アプリケーションの品質が向上する
フォームの処理を再利用しやすくなるので、DRYの原則に沿ったコーディングが可能になる

実装例

ユーザー登録フォームを例にForm Objectを実装します。

app/forms/user_registration_form.rb

class UserRegistrationForm
  include ActiveModel::Model

  attr_accessor :name, :email, :password

  validates :name, presence: true
  validates :email, presence: true, format: { with: URI::MailTo::EMAIL_REGEXP }
  validates :password, presence: true, length: { minimum: 6 }

  def save
    user = User.new(name: name, email: email, password: password)
    user.save
  end
end

app/controllers/users_controller.rb

class UsersController < ApplicationController
  def new
    @form = UserRegistrationForm.new
  end

  def create
    @form = UserRegistrationForm.new(user_params)
    if @form.save
      # 成功時の処理
    else
      render :new
    end
  end

  private

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