#目次
#1. はじめに
- この記事は、Rails初学者の工業大学三年生がRailsチュートリアルの学習記録を
つけるための記事です。 - 筆者自体がRailsやWebについて知識が少ないので、内容の解釈などに
間違いがある可能性があります。(その時はコメントで指摘してくださると助かります！) - Railsチュートリアル内ではRailsの内容以外にも、gitでのバージョン管理やHerokuを使ったデプロイも
学習しますが、gitに関しては既に私が学習済みのため学習記録には記述しません。 - 演習の記録も省略します。
#2. 第2章の概要
- scaffoldを使用したアプリ作成
- scaffoldとは
- scaffoldの使い方
- モデルの設計
- ユーザモデルの設計
- マイクロポストの設計
- MVCの挙動
- 実際のアプリケーションに近づけるために
- マイクロポストのバリデーション
- ユーザーとマイクロポストの関連付け
#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 |
| 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の処理の流れ
上の画像はユーザー一覧を表示するときの処理の流れを表したものです。
番号順に説明していきます。
①ブラウザから/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文字の文字数制限を付けて、
内容が空のマイクロポストは投稿できないようにバリデーションを行います。
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つのコードです。
class User < ApplicationRecord
has_many :microposts
end
class Micropost < ApplicationRecord
belongs_to :user
validates :content, length: { maximum: 140 }, presence: true # 140文字の文字数制限と存在性のバリデーション
end
#4. 終わりに
第2章は第1章の記事を投稿した次の日にまとめて終わらせることができたのですが、
記事を書く時間がなかなか取れず、投稿が遅れてしまいました。
第3章からは今回scaffoldによって自動生成された内容なども全て1から実装していくので、
内容も難しく量も多くなっていきます。
GWに入る前には次回の記事投稿までやりたいところです。