＠IT
アジャイル/DevOps
Coding Edge
Rails Hub
Railsアプリの設計をMVCごとに見直しリファクタリン...

Railsアプリの設計をMVCごとに見直しリファクタリングして連載総まとめ：開発現場でちゃんと使えるRails 4入門（12）（2/2 ページ）

» 2015年01月08日 18時00分公開

[著：林慶、監修：山根剛司，株式会社アジャイルウェア]

前のページへ 1|2 　　　　　　

モデルの見直し

　次に連載第5回の「ActiveRecordの基本機能とマイグレーション、バリデーション」で解説したMVCの「M」、モデルについて見直してみましょう。モデルは、その設計によって他のコンポーネントがシンプルに作れるようになるなど、重要な役割を担っています。モデルの設計を見直すことで、アプリケーションを洗練させることができます。

コントローラーのロジックの吸い取り

　先ほど「BooksController」の「index」アクションを見ましたが、以下のように「@books」の周辺があまりキレイではありませんでした。

def index
  @query = Query.new(params[:query])
  if @query.valid?
    @books = Book.where("title like :keyword OR author like :keyword", keyword: @query.keyword)
  else
    @books = Book.all
  end
end

　「@query」によって返すべき「Book」が異なるなら、その判定は「Book」が担うべきです。そこで「Book（app/models/book.rb）」に次の「search」スコープを定義します。

scope :search, ->(query=nil) {
  if query && query.valid?
    where("title like :keyword OR author like :keyword", keyword: query.keyword)
  else
    all
  end
}

　これにより「books#index」は次のように変更できます。このアクションのスペックを実行してもエラーは発生しておらず、コントローラーからモデルにロジックが移行していることが分かります。

def index
  @query = Query.new(params[:query])
  @books = Book.search(@query)
end

モジュールの活用

　複数のモデルで同じような関心事（concern）を抱えていることがあります。

　例えばPV数を保存する属性を持つ複数のモデルでは、いずれのモデルでもランキングを出力したいことがあります。また、画像のパスを保存する属性を持つ複数のモデルでは、ファイルサイズのバリデーションを実装したいことがあります。

　このように複数のモデルを横断する関心事は「concerns」モジュールによりまとめ上げるといいでしょう。ここではランキングを出力するスコープを定義するモジュールの例を示します。

module Ranking
  # 必要なカラム：'monthly_pv_count'、'weekly_pv_count'、'daily_pv_count'
  extend ActiveSupport::Concern
 
  included do
    scope(:ranking), ->(term) {
      avaival_term = %w(monthly weekly daily)
      if avaival_term.include?(term)
        order("#{term}_pv_count desc")
      else
        raise "不正な値です。'monthly'、'weekly'、'daily'のいずれかを渡してください。"
      end
    }
  end
end

　このモジュールを「app/models/concerns/ranking.rb」として保存します。「ActiveSupport::Concern」を「extend」したモジュールでは「included」のブロック中でスコープなどを定義できます。このモジュールを以下のようにモデルで読み込むことで「ranking」スコープがそれぞれで定義されます。

class Book < ActiveRecord::Base
  include Ranking
end
 
class Review < ActiveRecord::Base
  include Ranking
end

ビューの見直し

　最後に連載第8回の「RailsのテンプレートエンジンSlimの書き方とActionViewのヘルパーメソッド、レイアウトの使い方」で紹介したMVCの「V」、ビューです。ビューの見直しは、部分テンプレートやヘルパーにより共通部分を切り出すことで行います。

　また「yield」と「content_for」によりコンテンツを埋め込む方法もあります。それぞれ「Admin::BooksController」のビューを元に説明していきます。

部分テンプレートのおさらい

　部分テンプレートはビュー中の「render」メソッドで呼び出し、「_form.html.slim」のようにファイル名の先頭を「_」とするファイルに定義します。

/ app/views/admin/books/new.html.slim
= render partial: "form", locals: {book: @book, url: admin_books_path}
 
/ app/views/admin/books/_form.html.slim
= form_for book, url: url do |f|
  .field
    = f.label :title
    br
    = f.text_field :title    
  ……

　また、コレクションに対しては部分テンプレート名とローカル変数名を一致させることで次のように簡単に呼び出せます。以下の実装は全て同じ内容になります。

/ よくあるレンダリング
- @books.each do |book|
  = render partial: 'book', locals: {book: book}
 
/ このようにもできる
- @books.each do |book|
  = render book
  
/ このようにも
= render partial: 'book', collection: @books

ヘルパーの活用

　ヘルパーには、標準で用意されているヘルパー、「app/helpers」でモジュールに定義するヘルパー、コントローラーで定義したメソッドをヘルパーメソッドとして使えるように宣言したヘルパーの3種類があります。

　開発者が自ら定義するヘルパーはビューだけで使う場合は「app/helpers」で、コントローラーでも使う場合はコントローラーで定義するといいでしょう。

「yield」の活用

　これまで「yield」はレイアウトで一度呼び出すだけでした。しかし、実は「yield」は複数設定できます。

　以下のレイアウトではシンボルを渡した「yield」があり、そこに埋め込まれるコンテンツの有無を判定する「content_for?」メソッドによってレイアウトが切り替わります。

doctype html
html lang="ja"
  head
    title BookLibrary
    = stylesheet_link_tag "application", media: "all", "data-turbolinks-track" => true
    = javascript_include_tag "application", "data-turbolinks-track" => true
    = csrf_meta_tags
 
    - if content_for?(:side)
      .side
        = yield(:side)
 
      .main
        = yield
 
    - else
      .full
        = yield

　「yield(:side)」に埋め込まれるコンテンツがないとき、このレイアウトは従来と同じように挙動します。そして「yield(:side)」に埋め込むコンテンツはビューの中で次のように定義します。

= content_for(:side) do
  h2 サイドカラム
  
h2 メインカラム

例：app/views/welcome#index.html.slim

　このように「content_for」の引数で指定した「yield」に埋め込むコンテンツをブロック中で定義します。サイドバーやフッターなどで使うことが想定されていますが、実際のところは都度定義する必要があるのでレイアウト中で部分テンプレートを呼ぶ方がよく見られる気がします。

1日あれば、あのイカしたサービスのあのイカした機能を再現できる

　他にも見直す箇所はいくらでもありますが、MVCのコンポーネントをそれぞれ説明できたので本連載のおさらいはここまでとします。残りの改善箇所については「book_library」の「11」ディレクトリを参照してください。

　また今回をもちまして筆者（林慶）による予定されている連載は終了となります。これまで支えてくださった関係者の方、そして読者の方に感謝の気持ちを表したいと思います。

　Railsの最初のハードルは「rails g scaffold article title:string body:text」でブログを作ることです。そこからのハードルは1日かければ乗り越えられるものがほとんどでした。だから「1日あれば、あのイカしたサービスのあのイカした機能を再現できるんだ、どんなもんだい」ってな気分になれるのがRails開発の楽しいところだと私は思っています。

　皆さんも、ぜひ楽しいRails開発を見つけてください。それでは。

著者プロフィール

林慶（Rails技術者認定シルバー試験問題作成者）

平成2年大阪生まれ。2006年から高専で情報工学を学んでいたが当時は所謂プログラミングができない工学生だった。卒業後、高専の専攻科に上がったもののマンネリ化したキャンパスライフに飽きたため休学して渡豪。そこでプログラミングに対するコンプレックスを克服するためにRuby on Railsなどでアプリケーションを作ることを覚える。

帰国後から現在までは復学し推薦システムに関する研究を行いながら、アジャイルウェアでRuby on Railsアプリケーションの開発業務に従事している。

好きなメソッドはinject。