#目次

1. はじめに
2. 第2章の概要
3. 学習内容
4. 終わりに

#1. はじめに

この記事は、Rails初学者の工業大学三年生がRailsチュートリアルの学習記録を
つけるための記事です。
筆者自体がRailsやWebについて知識が少ないので、内容の解釈などに
間違いがある可能性があります。(その時はコメントで指摘してくださると助かります！)
Railsチュートリアル内ではRailsの内容以外にも、gitでのバージョン管理やHerokuを使ったデプロイも
学習しますが、gitに関しては既に私が学習済みのため学習記録には記述しません。
演習の記録も省略します。

#2. 第2章の概要

scaffoldを使用したアプリ作成
1. scaffoldとは
2. scaffoldの使い方
モデルの設計
1. ユーザモデルの設計
2. マイクロポストの設計
3. MVCの挙動
実際のアプリケーションに近づけるために
1. マイクロポストのバリデーション
2. ユーザーとマイクロポストの関連付け

#3. 学習内容
###1. scaffoldを使用したToyアプリ作成
####1-1. scaffoldとは

①scaffoldでできること

scaffoldとは建築現場などで使用される「足場」という意味で、
webアプリケーションの開発においては、モデルやビュー、コントローラという開発上での足場を
まとめて作成してくれる機能を持ちます。

②scaffoldの注意点

scaffoldはたくさんのコードを自動で生成し、webアプリを高速で開発することが可能になるのですが、
自動で生成されたコードは複雑で量が多いためRailsに関する知識が身につきにくいです。
そして、エラーが発生したときの原因解明が難しくなったりするため、Railsチュートリアルでscaffoldを使用するのはこの章のみとなっています。

####1-2. scaffoldの使い方
scaffoldを使用するタイミングは、後述する「モデルの実装」で使用することになります。
モデルを作成するときにrails generate scaffold User name:string email:stringというコマンドを実行します。
scaffoldを使用せずにモデルを作成する場合はrails generate model User name:string email:stringというコマンドを実行します。
modelの部分がscaffoldになっていることが分かりますね。

###2. モデルの設計
ToyアプリはTwitterににたアプリで、ユーザーがマイクロポスト(ツイートのようなもの)を投稿できるアプリです。
そのアプリを作成するために、その2つの要素をモデル(テーブル)として定義していきます。
####2-1. ユーザモデルの設計

①ユーザーの属性

各ユーザーはIDと名前とメールアドレスという情報を持っています。
モデルはデータベースにおけるテーブルと同じようなもので、それぞれの属性はテーブルの列に相当します。
モデルを作成するときに先ほども登場した、
rails generate scaffold User name:string email:stringというコマンドを実行します。
このコマンドのname:stringという部分がユーザーがstring型のnameという列を定義し、
name:stringという部分がstring型のemailという列を定義しています。
idは自動で定義されるので、コマンドには入っていません。

usersテーブル	データ型
id	integer
name	string
email	string

①scaffoldにより作成されるもの

先ほどのコマンドによってusersモデルのほかにモデルをブラウザで一覧表示させたりできるWebインターフェイスが作成されます。
このインターフェイスとモデルを組み合わせて「リソース」、つまり今回の場合は「Usersリソース」と呼びます。
ブラウザでユーザー一覧などを表示させるビューとそのビューとURLを対応させるルーティング、
アクションを定義するためのコントローラが、自動生成されています。
下の表が生成されるルーティングとビューです。

URL	アクション	用途
/users	index	すべてのユーザーを一覧するページ
/users/1	show	id=1のユーザーを表示するページ
/users/new	new	新規ユーザーを作成するページ
/users/1/edit	edit	id=1のユーザーを編集するページ

####2-2. マイクロポストの設計
こちらはUsersリソースと共通する内容が多いので、違いがあるモデルの設計のみを記述します。
マイクロポストはTwitterのツイートと似ているもので、内容と対応するcontentと誰の投稿かを表すuser_idという属性を持ちます。

micropostsテーブル	データ型
id	integer
content	text
user_id	integer

####2-3. MVCの挙動
このアプリは前回作成したアプリと違い、自身で作成したモデルが存在します。
よってMVC(Model-View-Controller)パターンを基にアプリケーション全体の処理の流れを見ていきます。

①RailsにおけるMVCの処理の流れ

出典 https://yasunari-kainuma.com/2020/09/21/mvc/

上の画像はユーザー一覧を表示するときの処理の流れを表したものです。
番号順に説明していきます。

①ブラウザから/usersというURLリクエストがRailsサーバーに送信される
②/usersリクエストはルーターによってUsersコントローラ内のindexアクションに割り当てられる
③indexアクションによってUsersモデルにUser.all=すべてのユーザーを取り出すという命令を送る
④Usersモデルが命令を受けてデータベースからすべてのユーザーを取り出す
⑤データベースから取り出したユーザー一覧をモデルがコントローラに渡す
⑤Usersコントローラがユーザー一覧を@userという変数に代入してViewに渡す
⑦ビューに埋め込まれているRubyが実行されてHTMLが生成される
⑧生成されたビューをコントローラが受け取り、ブラウザに返す

以上の流れでユーザー一覧のページが表示されます。

①RESTアーキテクチャとは

scaffoldにより作成されたコントローラは一覧を表示するためのindexというアクション以外にも、
ユーザー情報を編集するeditアクションやユーザーを削除するdestroyアクションなど、
生成されてるビューの数以上のアクションが定義されています。
それぞれのアクションのルートを以下の表に示します。

HTTPリクエスト	URL	アクション	用途
GET	/users	index	すべてのユーザー一覧を表示するページ
GET	/users1	show	id=1 のユーザーを表示するページ
GET	/users/new	new	新規ユーザーを作成するページ
POST	/users	create	ユーザーを作成するアクション
GET	/users/1/edit	edit	id=1 のユーザーを編集するページ
PATCH	/users/1	update	id=1 のユーザーを更新するアクション
DELETE	/users/1	destroy	id=1 のユーザーを削除するアクション

この表のURLの列を見ると、同じURLが設定されてるアクションがあることが分かります。
ただ、それらのアクションはHTTPリクエストが異なっています。
これがRESTというアーキテクチャの特徴で、全てのリソースを作成、取得、更新、削除の4つの処理で管理していることを表しています。
その4つの操作を使い分けているのがHTTPリクエストの列で、4つの処理がPOST, GET, PATCH, DELETEに対応しています。

###3. 実際のアプリケーションに近づけるために
####3-1. マイクロポストのバリデーション
ツイートと同じように投稿するマイクロポストには140文字の文字数制限を付けて、
内容が空のマイクロポストは投稿できないようにバリデーションを行います。

models/micropost.rb

class Micropost < ApplicationRecord
  validates :content, length: { maximum: 140 }, presence: true # 140文字の文字数制限と存在性のバリデーション
end

####3-2.ユーザーとマイクロポストの関連付け
マイクロポストにはその投稿が誰のものであるかという情報を持ち、
その投稿主のユーザーが削除された時にマイクロポストも削除するといった2つのモデルが連動した処理が行われる時があります。
このような処理を実現するためにはユーザーとマイクロポストの関連付けが必要です。

出典 https://railstutorial.jp/chapters/a-demo-app?version=4.0#sec-demo_user_has_many_microposts

上の図がユーザーとマイクロポストの関係です。
一人のユーザーは複数のマイクロポストを投稿することになるので、
ユーザー1に対して複数のマイクロポストが存在するという関係になります。
マイクロポスト自体は1人のユーザーから作成されるので、1つのマイクロポストは1人のユーザーに属するという関係になります。
この関係を作り出すのが以下の2つのコードです。

models/user.rb

class User < ApplicationRecord
  has_many :microposts
end

models/micropost.rb

class Micropost < ApplicationRecord
  belongs_to :user
  validates :content, length: { maximum: 140 }, presence: true # 140文字の文字数制限と存在性のバリデーション
end

#4. 終わりに
第2章は第1章の記事を投稿した次の日にまとめて終わらせることができたのですが、
記事を書く時間がなかなか取れず、投稿が遅れてしまいました。
第3章からは今回scaffoldによって自動生成された内容なども全て1から実装していくので、
内容も難しく量も多くなっていきます。
GWに入る前には次回の記事投稿までやりたいところです。