アプリ開発を通して基本的なMVCの理解を深める

ShiftMateアプリ開発からMVCの仕組みをおさらいする

本記事では、実際に作成した「ShiftMate」アプリ開発から学びを深めた
Railsアプリの新規登録処理が実際にどのように流れるのか を
View ➡ Controller ➡ Strong Params ➡ Model ➡ ActiveRecord ➡ DB
の順に追って説明します

ShiftMateアプリについて解説したnote記事はこちら⇩

Routing

resources :staffs, only: [:index, :new, :create, :edit, :update, :destroy]

staffs_controllerに付随するルーティングはこちらです。

Routesを確認

これによりHTTP動詞とコントローラアクションが正しくルーティングされていることを確認します。

View の流れ

１、スタッフ一覧画面に遷移

<GET> /projects/:project_id/staffs (index)

２、一覧画面の「新規登録」ボタンを押し、新規登録画面に遷移

<GET> /projects/:project_id/staffs/new (new)

３、フォームから「名前」「役職」「コメント」を入力し「登録」ボタンを押す

<POST> /project/:project_id/staffs (create)

４、スタッフが新規保存され一覧に戻る

redirect_to /projects/:project_id/staffs

Controller

staffs_controller.rb

class StaffsController < ApplicationController
  before_action :set_project

  def index
    @staffs = @project.staffs
  end

  def new
    @staff = @project.staffs.new
  end

  def create
    @staff = @project.staffs.new(staff_params)
    if @staff.save
      redirect_to project_staffs_path(@project)
    else
      render :new, status: :unprocessabel_entity
    end
  end

  private

  def staff_params
    params.require(:staff).permit(:name, :position, :comment)
  end
end

Createメソッドが担う役割

１、フォームの入力を受け取る
２、Modelへ保存処理を依頼する
３、処理結果に応じて遷移を制御する

staff_params (Strong Parameters)

createアクション内のstaff_paramsはセキュリティの最重要部分であり
想定外の値が許可されないよう、許可されたキーだけ通すフィルターの役割を持つ
ここでは:name, :position, :comment のみを許可している

新規登録フォームのview

_form.html.erb

     <%= form_with model: [@project, staff], local: true do |f| %>
        <div class="mb-4">
          <%= f.label :name, "名前", class: "form-label fw-bold" %>
          <%= f.text_field :name, class: "form-control form-control-lg" %>
        </div>

        <div class="mb-4">
          <%= f.label :position, "役職", class: "form-label fw-bold" %>
          <%= f.text_field :position, class: "form-control", placeholder: "例: SV、OP" %>
        </div>

        <div class="mb-4">
          <%= f.label :comment, "備考", class: "form-label fw-bold" %>
          <%= f.text_field :comment, class: "form-control", maxlength: 15 %>
        </div>

        <div class="text-center">
          <%= f.submit "保存する", class: "btn btn-success btn-lg px-5 shadow-sm" %>
        </div>
      <% end %>

このviewの新規登録フォームに入力された
:name, :position, :comment がstaff_paramsとして保存され、ストロングパラメーターが機能し、それ以外のキーは通さないようになっている

@staff.saveが行っていること

• バリデーションチェック

staff.rb

class Staff < ApplicationRecord
  belongs_to :project

  validates :name, presence: true # name入力必須
  validates :position, presence: true # position入力必須
  validates :comment, length: { maximum: 15 } # 文字数制限
end

• SQL文を自動生成
• DBへINSERT
• 成功した場合true / 失敗したらfalseを返す

ここでActiveRecordはRubyオブジェクト➡データベースのデータに変換する
ORM（Object Relational Mapper）の役割を持っているため

@staff = Staff.new(name:"田中", position:"SV")
@staff.save

と書くだけで、Rails側が勝手にSQLを組み立ててくれる

実際に生成される SQL

ログを確認すると、、、

INSERT INTO "staffs" ("project_id", "name", "position", "comment", "created_at", "updated_at") 
VALUES (1, '田中', 'SV', 'コメント', '2025-12-28 18:21:10.322656', '2025-12-28 18:21:10.322656') 

このSQLをActiveRecordが自動生成し、実行している
これにより、新規スタッフの登録が成功となる。

保存に失敗した場合

else
  render :new, status: :unprocessable_entity
end

保存処理が失敗した時に、新規登録画面を再表示するための処理
status: :unprocessable_entityで HTTPステータスを422にし「リクエストが不正だった」ことを明示する
これがないとブラウザは「成功（200）」となりバグ検知が難しくなる場合があるため

redirect_to と renderの違い

• redirect_toはブラウザに別のURLを再度リクエストを命じる（画面遷移）
  保存後にredirect_to する理由としては、画面を再表示した際に、再度POSTが送信される二重投稿を防ぐため
  = POST/REDIRECT/GETパターンという

• renderは画面だけ描画する（URLは変わらない）

このため成功時はredirect_to、失敗時はrenderが基本パターンといえる

---

これまではRails処理の仕組みが”点”での理解でしたが、アプリ開発を通して”線”で一連の流れで理解を深めれました