ruby presentとは？Ruby/RailsでViewを整理する方法

By /

Ruby Present とは？ Ruby/RailsでViewを整理する方法 の詳細な説明

はじめに：Viewの複雑さと整理の必要性

Ruby on Rails は、Webアプリケーション開発を迅速に進めるための強力なフレームワークです。そのMVC（Model-View-Controller）アーキテクチャは、アプリケーションの構造を明確にし、開発効率を高めます。しかし、アプリケーションが成長し、機能が追加されるにつれて、特にView（表示層）が複雑になりがちです。

View はユーザーが直接目にする部分であり、ユーザー体験の質を大きく左右します。本来、View は Controller から渡されたデータを「表示すること」に専念すべきです。しかし、実際には、データの整形、条件分岐による表示内容の切り替え、リンクの生成、さらには計算など、さまざまなロジックが View ファイル（ERBやSlimなど）の中に記述されてしまうことが少なくありません。

このような View の複雑化は、以下のような問題を引き起こします。

  • 可読性の低下: HTMLタグの中にRubyコードが複雑に絡み合い、コードが読みにくくなります。どこまでが構造で、どこからがロジックなのかが曖昧になります。
  • メンテナンス性の低下: わずかな表示変更でも、複雑なロジックを読み解く必要があり、修正に時間がかかります。バグの混入リスクも高まります。
  • テストの困難さ: View ファイル内のロジックは、ユニットテストがしにくい傾向があります。表示結果を確認するためには、統合テストやフィーチャテストが必要になり、テストコードの記述と実行にコストがかかります。
  • コードの重複: 同じようなデータの整形や表示ロジックが、複数の View ファイルや View ヘルパーに分散して記述されることがあります。
  • デザイナーやフロントエンドエンジニアとの協業の妨げ: ロジックが View に混在していると、HTML/CSSの修正を担当するデザイナーやフロントエンドエンジニアがコードを理解しにくくなります。

これらの問題を解決し、View を本来の役割に集中させるための様々なパターンやテクニックが存在します。「Ruby Present」とは、特定の gem の名前を指すこともありますが、多くの場合、Ruby/Rails において Presenter パターン を利用して View のロジックを整理する手法全般を指す言葉として使われます。

この記事では、Presenter パターンとは何か、なぜそれが View の整理に有効なのかを掘り下げ、Ruby/Rails でどのように実装するかを詳細に解説します。また、Presenter の実装を助ける Draper という人気の gem についても紹介し、View ヘルパーや Partial など、他の View 整理方法との比較も行います。この記事を読むことで、あなたの Rails アプリケーションの View をよりクリーンで保守しやすい状態にするための知識が得られるでしょう。

Viewが抱える問題の詳細と整理の必要性

Rails の View は、ERB (Embedded RuBy) というテンプレートエンジンを使うことが一般的です（SlimやHamlなども使われます）。ERBでは、<%% %> や <%= %> タグを使って HTML の中に Ruby のコードを埋め込むことができます。この手軽さが、View にロジックが混入しやすい原因の一つです。

具体的なコード例を見てみましょう。例えば、ユーザー情報を表示する View があるとします。

“`erb
<%# app/views/users/show.html.erb %>

<%= @user.name %>さんのプロフィール

メールアドレス:
<%= @user.email %>

年齢:
<% if @user.date_of_birth.present? %>
<%= (Date.current - @user.date_of_birth).to_i / 365 %> 歳
<% else %>
年齢非公開
<% end %>

登録日:
<%= @user.created_at.strftime("%Y年%m月%d日") %>

ステータス:
<% if @user.is_active? %>
アクティブ
<% else %>
非アクティブ
<% end %>

<% if @user.admin? %>

このユーザーは管理者です。

<% end %>

<%# 他にも、プロフィール画像の表示、最終ログイン日時、権限による表示切り替えなど、様々なロジックが追加される可能性がある %>
“`

この簡単な例でも、View に以下のロジックが混入しています。

  • 年齢の計算 ((Date.current - @user.date_of_birth).to_i / 365)
  • 登録日のフォーマット (@user.created_at.strftime(...))
  • 生年月日が存在するかどうかの条件分岐 (if @user.date_of_birth.present?)
  • アクティブ状態による表示テキストと色の切り替え (if @user.is_active?)
  • 管理者かどうかの条件分岐 (if @user.admin?)

これらのロジックは、技術的には View に書くことは可能ですが、View の役割である「表示」の範疇を超えています。本来 View は「渡されたデータをどのように見せるか」に注力すべきです。「どのようなデータを渡すか」「データをどのように加工するか」は View の責任ではありません。

このような View は、以下のような具体的な問題を引き起こします。

  • テストのしにくさ: 年齢計算やステータス表示のロジックを変更した場合、それをテストするために RSpec の Capybara などを使ったフィーチャテストを書く必要があります。これは時間がかかり、実行も遅いです。Ruby のコードとして切り出されていれば、シンプルなユニットテストで高速に検証できます。
  • 再利用性の低さ: 例えば、ユーザーの年齢を他の View（一覧画面など）でも表示したい場合、同じ計算ロジックを再度記述するか、共通の View ヘルパーに切り出す必要があります。しかし、View ヘルパーも限界があります（後述）。
  • 保守コストの増加: もし年齢計算の方法が変わったり（例：閏年の考慮）、ステータス表示のルールが変わったりした場合、View ファイルを直接修正することになり、意図しない表示崩れやバグを招くリスクがあります。
  • 関心事の分離の違反: View がデータの取得（Controllerの仕事の一部）でもなく、データの永続化（Modelの仕事）でもなく、データの加工や表示ロジックを直接行うことは、MVCの原則である「関心事の分離 (Separation of Concerns)」に反します。

MVCアーキテクチャでは、それぞれの層が明確な責任を持ちます。

  • Model: アプリケーションのデータ構造、ビジネスロジック、データベースとの連携を担当します。
  • Controller: ユーザーからのリクエストを受け付け、Modelと連携して必要なデータを準備し、どのViewを表示するかを決定します。
  • View: Controllerから渡されたデータを受け取り、それをユーザーインターフェースとして表示します。Viewは表示以外のロジックを持つべきではありません。

しかし現実には、前述の例のように View が Controller から受け取った @user オブジェクトに対して直接メソッドを呼び出し、その結果を View の中で加工・整形して表示しています。この「加工・整形」の部分こそが、View を複雑にする主な原因です。

この問題を解決するために、View に渡すデータを View が扱いやすい形に事前に準備しておく専門のオブジェクトを導入するパターンが考えられます。それが Presenter パターン です。そして、Ruby/Rails の文脈でこのパターンを実装したものが「Ruby Present」と呼ばれる手法の一つです。

Presentersとは何か？ (Ruby Present)

Presenter パターンは、View と Model の間の仲介役として機能するオブジェクトを導入する設計パターンです。Presenter オブジェクトは、View が必要とするすべての表示用データを準備し、整形する責任を持ちます。View は Presenter から必要なデータを取り出し、それをそのまま表示するだけになります。

先ほどのユーザー情報の例で考えてみましょう。View が必要とするのは、ユーザーオブジェクトそのものではなく、以下の表示用のデータです。

  • ユーザー名 (加工不要)
  • メールアドレス (加工不要)
  • 整形済みの年齢文字列 (例: “35 歳” または “年齢非公開”)
  • 整形済みの登録日文字列 (例: “2023年10月26日”)
  • 表示用のステータステキスト (例: “アクティブ” または “非アクティブ”)
  • ステータスに応じた表示用のスタイル情報 (例: “color: green;” または “color: gray;”)
  • 管理者であるかどうかの真偽値 (Viewで条件分岐に使う)

Presenter オブジェクトは、Controller からユーザーオブジェクトを受け取り、これらの表示用データを生成するメソッドを提供します。

View Helpers との違い

Rails には View のロジックを切り出すための仕組みとして View Helpers があります。View Helper は、モジュールとして定義され、View や Controller で共通して使えるメソッド集です。

“`ruby

app/helpers/users_helper.rb

module UsersHelper
def user_age(user)
if user.date_of_birth.present?
(Date.current – user.date_of_birth).to_i / 365
else
“年齢非公開”
end
end

def formatted_registration_date(user)
user.created_at.strftime(“%Y年%m月%d日”)
end

def user_status_label(user)
if user.is_active?
content_tag(:span, “アクティブ”, style: “color: green;”)
else
content_tag(:span, “非アクティブ”, style: “color: gray;”)
end
end
end
“`

そして View では以下のように呼び出します。

“`erb
<%# app/views/users/show.html.erb %>

<%= @user.name %>さんのプロフィール

メールアドレス:
<%= @user.email %>

年齢:
<%= user_age(@user) %> 歳 <%# ヘルパーメソッドの呼び出し %>

登録日:
<%= formatted_registration_date(@user) %><%# ヘルパーメソッドの呼び出し %>

ステータス:
<%= user_status_label(@user) %><%# ヘルパーメソッドの呼び出し %>

<% if @user.admin? %> <%# この条件分岐はまだViewに残っている %>

このユーザーは管理者です。

<% end %>
“`

View Helper を使うことで、View 内の複雑なRubyコードを減らし、ロジックを再利用できるようになります。これは View の整理に有効な手段の一つです。

しかし、View Helper にも限界があります。

  1. グローバルな名前空間汚染: Helper メソッドは View 全体で利用可能になるため、メソッド名が衝突するリスクがあります。また、どの Helper モジュールにどのメソッドがあるのかが分かりにくくなることがあります。
  2. オブジェクト指向性の欠如: Helper メソッドは手続き的な関数です。特定のオブジェクト（例: @user）に関連する複数のヘルパーメソッドが、バラバラの Helper モジュールに定義される可能性があります。これは、そのオブジェクトに関する表示ロジックが一箇所にまとまらないことを意味します。
  3. 状態を持てない: Helper メソッドはステートレスであるため、複数の View 要素にまたがるような、状態を保持する必要がある複雑な表示ロジックには向きません。

Presenter は、これらの View Helper の限界を克服します。Presenter は特定のオブジェクト（例えば User モデルのインスタンス）に「紐づいた」オブジェクトです。View は Presenter オブジェクトのインスタンスメソッドを呼び出す形でデータにアクセスします。これにより、関連する表示ロジックが一つのクラス内にカプセル化され、オブジェクト指向的に View を整理できます。Presenter はインスタンス変数などを使って状態を持つことも可能です。

Model、Controller との違い

  • Model: Presenter はビジネスロジックやデータベース操作を行いません。Presenter は Model からデータを受け取り、表示用に整形するだけです。
  • Controller: Controller はリクエスト処理とデータ準備（Modelからのデータ取得）を行い、Presenter のインスタンスを生成して View に渡す役割を担います。表示用の整形ロジックは Presenter に任せます。

Presenter は、Model と View の間に位置し、View のためのデータ提供に特化した「View Object」または「Presentation Object」として機能します。

Presenter パターンの目的とメリット

Presenter パターンの主な目的は、View を純粋な「表示」に特化させることです。その結果、以下のようなメリットが得られます。

  • 可読性の向上: View ファイルにはHTML構造と、Presenterから受け取ったデータを表示するシンプルなコードだけが残ります。ロジックがPresenterに移動するため、Viewが非常に読みやすくなります。
  • テスト容易性の向上: View のロジック（データの整形、条件分岐など）が Presenter クラスのメソッドとして切り出されるため、Presenter クラスに対してシンプルなユニットテストを書くことができます。これは View ファイルそのものをテストするよりもはるかに高速で容易です。
  • 再利用性の向上: 同じ Presenter オブジェクトを異なる View で使うことができます。また、Presenter クラス内のメソッドは、その Presenter オブジェクトを表示する様々な View で共通して利用できます。
  • 関心事の分離: View、Presenter、Controller、Model の各層の責任が明確になり、コードベース全体の構造が整理されます。
  • メンテナンス性の向上: 表示ロジックの変更が必要な場合、Presenter クラスを修正すればよく、影響範囲が限定されます。
  • チーム開発における役割分担の明確化: バックエンド開発者（Model/Controller/Presenter）とフロントエンド開発者（View/HTML/CSS/JavaScript）が、それぞれの関心事に集中しやすくなります。

「Ruby Present」という言葉は、このような Presenter パターンを Ruby 言語、特に Rails フレームワーク上で実装する際に用いられる表現として理解すると良いでしょう。特定の標準ライブラリや組み込み機能ではなく、あくまで設計パターンとその実装手法を指します。

Presenterの実装方法 (Ruby/Rails)

Presenter パターンは、特別な gem を使わなくても、シンプルな Ruby クラスとして実装できます。ここでは、手動での Presenter の実装方法と、それを Rails アプリケーションに組み込む方法を解説します。

基本的な実装：シンプルな Ruby クラスとして定義

Presenter は、通常、表示対象となる Model オブジェクトを初期化時に受け取るシンプルな Ruby クラスです。慣習として、対象モデル名Presenter のような名前が付けられます (例: UserPresenter, ProductPresenter)。これらのクラスは、View が必要とする表示用データを提供するメソッドを持ちます。

例として、User モデルの Presenter を作成します。

まず、Presenter クラスを配置するディレクトリを作成します。慣習的に app/presenters や app/view_objects といったディレクトリ名が使われます。ここでは app/presenters とします。

bash
mkdir app/presenters

次に、UserPresenter クラスを作成します。

“`ruby

app/presenters/user_presenter.rb

class UserPresenter
# Presenterは表示対象となるオブジェクト（ここではUserインスタンス）を保持する
def initialize(user)
@user = user
end

# Viewが必要とする表示用データを提供するメソッドを定義する

def name
@user.name
end

def email
@user.email
end

# 年齢を計算して整形するメソッド
def age
if @user.date_of_birth.present?
“#{(Date.current – @user.date_of_birth).to_i / 365} 歳”
else
“年齢非公開”
end
end

# 登録日を整形するメソッド
def formatted_registration_date
@user.created_at.strftime(“%Y年%m月%d日”)
end

# ステータスに応じた表示テキストを返すメソッド
def status_text
@user.is_active? ? “アクティブ” : “非アクティブ”
end

# ステータスに応じた表示用スタイル（HTML属性値）を返すメソッド
def status_style
@user.is_active? ? “color: green;” : “color: gray;”
end

# 管理者かどうかを判断するメソッド (Viewの条件分岐で使う)
def admin?
@user.admin?
end

# 元のモデルオブジェクトのメソッドを View から直接呼び出したい場合
# delegate を使うと、Presenter経由で @user のメソッドを呼び出せる
# 例: @user.id を取得したい場合
delegate :id, to: :@user

# 複数のメソッドを delegate する場合
# delegate :id, :created_at, :updated_at, to: :@user
end
“`

この UserPresenter クラスは、User オブジェクトを受け取り、View が必要とする整形済みのデータをメソッドとして提供します。年齢計算、日付フォーマット、ステータス表示ロジックなどが Presenter に移動しました。

Rails での統合：Controller から View への渡し方

Presenter オブジェクトは Controller でインスタンス化され、View に渡されます。

“`ruby

app/controllers/users_controller.rb

class UsersController < ApplicationController
def show
user = User.find(params[:id])
# User オブジェクトを UserPresenter でラップ（くるむ）する
@user_presenter = UserPresenter.new(user)
end
end
“`

Controller では、User.find(params[:id]) で取得した @user オブジェクトそのものではなく、それを引数として UserPresenter.new を呼び出し、生成した Presenter オブジェクトを View に渡す変数（ここでは @user_presenter）に代入します。

Rails での統合：View からの利用方法

View では、Controller から渡された Presenter オブジェクトのメソッドを呼び出してデータを表示します。

“`erb
<%# app/views/users/show.html.erb %>

<%# Controllerから渡された @user_presenter を使う %>

<%= @user_presenter.name %>さんのプロフィール

メールアドレス:
<%= @user_presenter.email %>

年齢:
<%= @user_presenter.age %> <%# Presenterのageメソッドを呼び出す %>

登録日:
<%= @user_presenter.formatted_registration_date %> <%# Presenterのメソッドを呼び出す %>

ステータス:
<%# Presenterのstatus_textとstatus_styleメソッドを呼び出す %>
このユーザーは管理者です。

<% end %>

<%# 元のモデルのIDが必要な場合（delegateを使っている場合） %>

ユーザーID: <%= @user_presenter.id %>

“`

View は非常にシンプルになりました。HTML構造と、Presenter オブジェクトから値を取り出して表示するコードだけです。View には条件分岐が残っていますが、それは表示するかしないかという View 本来のロジックであり、データの加工や整形は一切行っていません。

delegate メソッドの活用

多くの Presenter は、ラップしている元の Model オブジェクトの属性やメソッドを、そのまま View から利用できるようにしたい場合があります。例えば、ユーザーID (@user.id) や更新日時 (@user.updated_at) などです。

Presenter クラスにこれらのメソッドを一つずつ定義するのは手間です。Ruby の delegate メソッドを使うと、これを簡単に行うことができます。delegate :method_name, to: :@instance_variable と記述すると、その Presenter オブジェクトに対して method_name が呼び出された際に、内部的に @instance_variable.method_name を呼び出してその結果を返します。

UserPresenter の例に delegate を追加したのが以下のコードです（再掲）。

“`ruby

app/presenters/user_presenter.rb

class UserPresenter
def initialize(user)
@user = user
end

# @user オブジェクトの id, name, email, created_at, admin? メソッドを
# UserPresenter オブジェクト経由で呼び出せるようにする
# name, email, admin? は上記で個別に定義したが、delegateでも良い
# delegate で定義した場合、明示的にメソッドを定義するよりも優先順位が低い（通常）
delegate :id, :name, :email, :created_at, :updated_at, :admin?, to: :@user
# ただし、age, formatted_registration_date, status_text, status_style など
# Presenterで加工・整形するメソッドは個別に定義する必要がある

# 年齢を計算して整形するメソッド (加工しているので個別に定義)
def age
if @user.date_of_birth.present?
“#{(Date.current – @user.date_of_birth).to_i / 365} 歳”
else
“年齢非公開”
end
end

# 登録日を整形するメソッド (加工しているので個別に定義)
def formatted_registration_date
@user.created_at.strftime(“%Y年%m月%d日”)
end

# ステータスに応じた表示テキストを返すメソッド (加工しているので個別に定義)
def status_text
@user.is_active? ? “アクティブ” : “非アクティブ”
end

# ステータスに応じた表示用スタイル（HTML属性値）を返すメソッド (加工しているので個別に定義)
def status_style
@user.is_active? ? “color: green;” : “color: gray;”
end

# Viewヘルパーメソッドを使いたい場合、ApplicationController.helpers などを使う
# 例: link_to を使いたい場合
def profile_link
# Rails.application.routes.url_helpers を include するか
# ApplicationController.helpers を使うか
# あるいは、Draperのようなgemを使うと簡単にヘルパーメソッドが使える
# ここでは単純な例としてHelperモジュールをincludeしてみる (ただし、Controller/Viewのコンテキストに依存するので注意が必要)
# include ActionView::Helpers::UrlHelper # 例
# link_to name, user_path(@user) # 例
# 手動実装の場合は、引数としてヘルパーメソッドを受け取るなど、より設計を検討する必要がある
# 簡単な例: link_toは使わず、URLだけを生成する
Rails.application.routes.url_helpers.user_path(@user)
end

# あるいは、View Helper メソッドそのものを Presenter に引き渡す（より一般的）
# def initialize(user, view_context = nil)
# @user = user
# @view = view_context # Viewコンテキストを保持
# end
#
# def profile_link
# @view.link_to name, @view.user_path(@user) if @view
# end
#
# Controllerで渡す: @user_presenter = UserPresenter.new(user, view_context)
#
# Draper gem を使うとこの辺りが簡単に解決される (後述)
end
“`

delegate を使うことで、Presenter は View が必要とする元のモデルの属性やメソッドへのアクセスを透過的に提供しつつ、表示用に加工・整形が必要なメソッドだけを個別に定義すればよくなります。

View Helper メソッドの利用について補足:
手動で Presenter を実装する場合、link_to や image_tag のような View Helper メソッドを Presenter 内で直接使うのは少し複雑です。これらのヘルパーメソッドは View や Controller のコンテキストに依存するため、Presenter にそのコンテキストを渡す必要があります。上記のコメントで触れたように、初期化時に view_context を渡す方法や、特定のヘルパーモジュールを include する方法などがありますが、これは手動実装の煩雑さの一つです。後述する Draper gem は、この View Helper の利用を非常に簡単にしてくれます。

実装例：商品情報の表示

別の例として、商品情報を表示する ProductPresenter を考えます。

“`ruby

app/presenters/product_presenter.rb

class ProductPresenter
def initialize(product)
@product = product
end

delegate :name, :description, :price, :stock_quantity, :image_url, to: :@product

# 価格を通貨記号付きで整形するメソッド
def formatted_price
“¥#{price.to_s(:delimited)}” # 例えば、価格がInteger/Decimalの場合
end

# 在庫状況に応じた表示テキストを返すメソッド
def stock_status_text
if stock_quantity > 10
“在庫あり”
elsif stock_quantity > 0
“残りわずか”
else
“在庫切れ”
end
end

# 在庫状況に応じた表示スタイル（HTML属性値）を返すメソッド
def stock_status_style
if stock_quantity > 10
“color: green;”
elsif stock_quantity > 0
“color: orange;”
else
“color: red;”
end
end

# 商品画像を表示するタグを生成するメソッド (View Helperを使いたい場合)
# 手動実装では View Helper 利用は複雑なので、ここでは画像URLだけを返す
def image_tag_url
image_url || “no_image.png” # 画像URLがない場合はデフォルト画像
end

# セール価格がある場合の表示ロジックなど…
end
“`

Controller:

“`ruby

app/controllers/products_controller.rb

class ProductsController < ApplicationController
def show
product = Product.find(params[:id])
@product_presenter = ProductPresenter.new(product)
end
end
“`

View:

“`erb
<%# app/views/products/show.html.erb %>

<%= @product_presenter.name %>

<%# “><%= @product_presenter.stock_status_text %>

説明:
<%= simple_format(@product_presenter.description) %> <%# View Helper (simple_format) と Presenter を併用する例 %>

<%# その他の情報（レビュー、関連商品など） %>
“`

この例でも、価格のフォーマットや在庫状況による表示ロジックが Presenter に切り出され、View がシンプルになっています。

Collections (リストの表示) の Presenter 化

複数のオブジェクト（リスト）を表示する場合も、それぞれのオブジェクトを Presenter でラップしてから View に渡すのが一般的です。

“`ruby

app/controllers/users_controller.rb

class UsersController < ApplicationController
def index
users = User.all # またはページングされたユーザーリスト
# 各ユーザーオブジェクトを UserPresenter でラップする
@user_presenters = users.map { |user| UserPresenter.new(user) }
end
end
“`

View:

“`erb
<%# app/views/users/index.html.erb %>

ユーザーリスト

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール