はじめに

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

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

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

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

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

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

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

Decoratorについて

Decoratoには、特定のモデルのデータを整形してビューで表示するための処理を記述します。

例えば、UserControllerに以下のコードがあるとします。

def show
  @user = User.find(params[:id])
  @full_name = "#{user.name} #{user.surname}"
  @full_address = "#{user.country} #{user.city} #{user.street}"
end

このコントローラーのコードにはHTTPリクエストに対する処理以外が含まれているため、単一責任の原則に反しています。また、フルネームやフルアドレスは別の処理でも使う可能性があるため、DRY原則に反しています。

このようなコードが蓄積されていくとファットコントローラーが出来上がってしまいます。

そこで、フルネームやフルアドレスの処理をモデルに移動してみます。

class User < ApplicationRecord
  def full_name
    "#{name} #{surname}"
  end

  def full_address
    "#{country} #{city} #{street}"
  end
end

それぞれをメソッド化することでDRY原則には反しなくなりました。また、特定のモデルのデータに依存する処理をモデルに記述しているので、単一責任の法則にも反しなくなりました。

しかし、厳密に言うとこのコードはモデルに記述すべきではありません。このコードは特定のモデルのデータを整形してビューに表示するための処理を記述しているため、モデルではなくDecoratorに記述すべきです。

Decoratorというロジック層はRuby on Railsで仕組みが用意されているわけではないので、別途Gemをインストールするなどして用意する必要があります。

Draperについて

DraperとはRuby on RailsにDecoratorを簡単に導入することができるGemです。

導入

Gemfileに以下を追記してbundle installを行います。

Gemfile

gem 'draper'

次に、以下のコマンドを実行して特定のモデル専用のDecoratorを作成します。

% rails generate decorator User

実装

作成したUserDecoratorに以下を記述します。

app/decorators/user_decorator.rb

class UserDecorator < Draper::Decorator
  delegate_all

  def full_name
    "#{object.name} #{object.surname}"
  end

  def full_address
    "#{object.country} #{object.city} #{object.street}"
  end
end

delegate_allとは、親モデルに定義したインスタンスメソッドをDecoratorで使用するための記述です。これにより、Userモデルに定義したインスタンスメソッドをUserDecoratorで使用することができます。

用意したDecoratorをビューなどで使用するには以下の2通りの方法があります。

app/views/users/show.html.erb

<%= @user.decorate.full_name %>
<%= @user.decorate.full_address %>

Userモデルのインスタンス変数からこのように呼び出すことができます。

毎回.decorateをつけて呼び出すのが煩雑に感じるという場合、コントローラーでUserモデルのインスタンス変数を作成するときにUserDecoratorでラップする方法があります。

app/controllers/user_controller.rb

def show
  @user = User.find(params[:id]).decorate
end

インスタンス変数はラップされてビューに渡されるので、ビューではUserDecoratorのメソッドをそのまま呼び出すことができます。

app/views/users/show.html.erb

<%= @user.full_name %>
<%= @user.full_address %>

まとめ

MVCフレームワークで構築したWebシステムの規模が大きくなればなるほど「ファットコントローラー」や「ファットモデル」という課題に悩まされることが多くなります。

歴史の長いシステムほどこの課題を抱える傾向があるものの、日々の機能開発に追われてデザインパターンの見直しにまで手が回らないというのもよく聞く話です。

もし「ファットコントローラー」や「ファットモデル」に悩まされているという場合、デザインパターンの導入を検討してみてはいかがでしょうか。