Helperを使わない理由

RailsのHelperはビューで使用できるメソッドを定義するモジュールです。ApplicationHelperにメソッドを追加すると全てのビューで呼び出し可能になります。

一見便利に見えますが、実際のプロジェクトでHelperを積極的に使用すると以下の問題が蓄積します。

なぜHelperを避けるのか？

1. グローバルスコープ汚染

Rails Helperはデフォルトで全ビューにincludeされます。PostsHelperに定義したメソッドがUsersControllerのビューでも呼べます。結果: Helperファイルが増えるほどネームスペース衝突リスクが高まり、メソッドの定義場所の追跡が困難に。

2. データ加工ロジックの間違った場所

DB照会、配列変換、条件付きデータ加工がHelperに入るとMVC境界が崩れます。

# ❌ Bad — Helperにデータ加工
def recent_posts_for_sidebar
  Post.published.order(created_at: :desc).limit(5)
end

# ✅ Good — Controllerで準備
# controller
@recent_posts = Post.published.order(created_at: :desc).limit(5)

Controllerから@インスタンス変数で渡せばフローが一目で分かります: リクエスト → Controller（データ準備） → View（表示）。

3. テスト困難

Helperメソッドはビューコンテキスト（selfがActionView）で実行されます。url_for、content_tag、t()に依存した瞬間、単体テストでこのコンテキストを再現する必要があります。

4. 肥大化するHelperファイル

Helperは「雑多な引き出し」になりやすいです。分類基準が曖昧で、関連のないメソッドが積み上がります。

5. 意図しない削除事故

Helperメソッド名は平凡な場合が多い: format_date、status_label、badge_color等。Helperはグローバルなため、定義ファイルと実際の使用箇所が全く異なる場所にあることがあります。リファクタリング中に使われていないと思って削除すると、全く別のビューでundefined methodエラーが発生します。

代替案

推奨: Decorator / Presenterパターン

Helperの根本問題はモデルに属する表示ロジックがグローバル関数として漂っていること。Decoratorはこのロジックをモデルオブジェクトにラップして解決します。

# app/decorators/user_decorator.rb
class UserDecorator < SimpleDelegator
  def badge_color
    active? ? 'green' : 'gray'
  end

  def display_name
    name.presence || email.split('@').first
  end
end

# Controller
def show
  @user = UserDecorator.new(User.find(params[:id]))
end

# View — 普通のモデルのように使う
<span class="bg-<%= @user.badge_color %>-500"><%= @user.display_name %></span>

その他の代替案

• Controller @変数: データ加工/照会用

• ビューインライン: 1〜2箇所で使う三項演算子レベルの表示ロジック

• Partial: 再利用可能なUI断片

• Service Object: 複雑なビジネスロジック