🏗️

MVCパターン

Model-View-Controller — Railsのコアアーキテクチャ

MVC（Model-View-Controller）はソフトウェア設計パターンで、Railsの基盤です。

Model: データとビジネスロジックを担当します。データベーステーブルと1:1でマッピングされ、ActiveRecordを通じてSQLなしでデータを操作できます。バリデーション、関連設定、コールバック等もModelで処理します。

View: ユーザーに表示される画面を担当します。ERB（Embedded Ruby）テンプレートでHTML内にRubyコードを挿入します。レイアウト、パーシャル（partial）で再利用可能なUI部品を作ります。

Controller: HTTPリクエストを受けて適切なModelを呼び出し、結果をViewに渡す仲介者です。認証、権限確認、パラメータ処理等を担当します。

Railsでのリクエストフロー: ブラウザ → ルーター → Controller → Model（DB照会） → Controller（データ渡し） → View（HTML生成） → ブラウザ

構造ダイアグラム

🌐 Browser — GET /posts/1
↓
Router
config/routes.rb
posts#show
↓
💎
Model
Post.find(1)
app/models/
🎮
Controller
@post = Post.find
app/controllers/
📄
View
<%= @post.title %>
app/views/
Controller → Model (DBクエリ) → Controller (@post) → View (HTML)
↓
🌐 Browser — HTMLレンダリング
ポイント: <strong>ControllerがModelとViewを仲介</strong> — 関心事を分離してコード構造を明確に維持

キーポイント

1

ユーザーがブラウザからURLリクエスト（例: GET /posts/1）

2

config/routes.rbでURLをController#Actionにマッピング（posts#show）

3

PostsController#showが実行 — @post = Post.find(params[:id])

4

Model(Post)がActiveRecordを通じてDBからデータ取得

5

Controllerが@postインスタンス変数をViewに渡す

6

View(show.html.erb)が@postデータをHTMLにレンダリングしてブラウザに返す

メリット

  • ✓ 関心の分離 — コード構造が明確
  • ✓ チーム協業が容易（デザイナー=View、開発者=Model）
  • ✓ Railsの規約で自動マッピング
  • ✓ コードの再利用性が高い

デメリット

  • ✗ 簡単なアプリには過度な構造
  • ✗ Controllerが肥大化しやすい（Fat Controller）
  • ✗ Modelが責任を持ちすぎる（God Model）
  • ✗ Service Object等の追加パターンが必要な場合がある

ユースケース

全てのRailsアプリケーション RESTful APIサーバー 管理者ダッシュボード Eコマースサイト
📏 Convention over Configuration →