Lesson#4MVCとルーティング

Railsは、はじめにMVCとルーティングのことを理解しておくだけでだいぶ違う！

こんにちは、はくたむです。
侍エンジニア塾で授業を開始してそろそろ1ヵ月が経とうとしています。
勉強の進捗としてはやっとRailsを触り始めたといったところでしょうか。
4回目のレッスンが終わりましたので、今回もレッスンの内容をまとめていきたいと思います！
また、レッスンの内容だけでなくスクールに入っての感想とか勉強や転職について私がどんなことをしているかなんかもそのうちまとめていきたいと思っています。

Railsは、はじめにMVCとルーティングのことを理解しておくだけでだいぶ違う！
- 課題のフィードバック
  - MVCとルーティング
- 補足
Railsってどこまで理解すればいいんだ…？
Railsが今何をやっているのか？！を知りたい
次回の課題

課題のフィードバック

まずは恒例の課題のフィードバックから。

サーバーの仕組みについて復習しておく
これは正直ささっとネットでおさらいしただけです。笑
インターネットの仕組みとか、WEBページを表示するときクライアント側とサーバー側でどういうことが行われているのか、など、本当に基礎的なところです。

MVCとルーティングについてまとめてQiitaに投稿する

https://qiita.com/hak_chami/items/1c468ccce9a29d43d307qiita.com

実際にやる前に調べるのって、本当に文字だけの情報しかないから正直すっごいイメージしにくくて分かりづらいんですよね。
でもここで頑張ってRailsの考え方を学んでおくことで、実際触ってみた時に余計な混乱もなくスッと入っていけた気がします。

実際やってみてそうだったんですが、Railsって本当にルーティングとMとVとCの繰り返しでできているんですね。一旦言葉から調べて最後自分で図を作ったら関係性がよくわかりました。

ちなみに前回言語について調べるときはサーチ不足により突っ込まれた箇所があったので今回は徹底的に潰したんですが、めっちゃ時間がかかりました。笑
でも時間をかけるだけの価値がここにはあったと思います。

MVCとルーティングについてはここにもサラッと記載しておきますね。

ちなみにこのMVCとルーティングの考え方は他のフレームワークでも取り入れているものがあるし、MVCでなくても根本的な考え方は似ているというのもあるそうで、一度きちんと理解しておくと他のものを触ったときでも理解がしやすいそうです。

MVCとルーティング

M：Model

データベースを操作する仕組み
Controllerからデータの追加や変更・削除の指示を受け実行する。
データベースのテーブルごとにModelが用意されている。
データベースのテーブルはモデルクラスとモデルクラスから生成されたインスタンスによって作られている。

V：View

ユーザに見せるインターフェイスのデザイン
Viewは通常複数用意されており、おのおのHTMLのテンプレートのような形になっている。
テンプレートの中にはRubyのコードが埋め込んであり、要求されたアクションに応じて該当のテンプレートにControllerがModelから受け取ったデータを反映し、HTMLを生成する。

C：Controller

ユーザーリクエストをModelやViewと連携させる仕組み
ユーザーからのリクエストを受けModelから必要な情報を受け取り、Viewによって生成されたHTMLを画面に反映させる。
ModelとViewに指示を出す司令塔のような役割。
Viewと同じく複数用意されており、さらに1つのControllerの中に複数のアクションが用意されている。

アクション＝アクションメソッド
ユーザーからのリクエストに対して具体的な処理を実行するためのメソッド。

ルーティング

URLとアプリケーションを結びつける仕組み
ユーザーがブラウザを経由してアクセスしたURLとコントローラーのアクションを結びつける（＝処理を割り振っている）役割。
コントローラーの一部のようなもの。

MVCとルーティングの関係を図にしたもの

これまでの情報をまとめて図にしてみました。

MVCとルーティングの図

補足

DRY：Don't Rpeat Yourself（同じことを繰り返さない）

DRYの法則を守るためには

メソッド化する
ビフォアアクションを使う
ライブラリを使う

このようなものを使い、なるべく同じ記述を色々なところに書かないようにする。

CoC:Convention over Configuration（設定より規約）

Railsの基本となる7つのアクション

index
show
new
edit
create
update
destroy

これらを使い作っていくことが規約に沿って作ることになる。
使っていくうえで必要な設定はRails側ですでに用意されているので、簡単に使うことができる。

データベースと繋がらないModel

これは中級者以降の話ですが、ということだったんですが、Modelは必ずしもDBと結びついているわけではない。
例えば、新規登録した後にTwitterにツイートするというアクションがあったとして、これはControllerの中に書いてしまっても動くには動くのだけど、本来Controllerの役割というのは上述の通りユーザーリクエストをModelやViewと連携させる仕組み であって、それ以上の機能を持たせることは望ましくない。
この場合、Modelの中にその仕組み（ビジネスロジック）を記述することが多々あるのだそう。
Modelフォルダの中に素のRubyのファイルを作って記述する場合、ApplicationRecordは継承しないclassを作成する。
また、Modelに書かず切り分けする場合もあるそうなのですが、このあたりはチーム開発する場合チームで方向性を決めていくことになるそうです。

Railsってどこまで理解すればいいんだ…？

単純な疑問だったのですが。
例えば、Railsでは最初に

$ rails new アプリケーション名

ってするとズバババッ！ってすごい勢いでフォルダが作られていくじゃないですか。
そんな感じでRailsがやっていることに対してどこまで理解しておけばいいんだろう…って勉強しながら思っていました。
で、先生に聞いたんですが、答えとしては

現段階ではRailsの使い方を理解できていればOK。

Rails自体の仕組み（元のRuby）を理解するにはGitHubでソースコードを読んでいくことになるのだけど、これは今後必要になった段階でやればいいことなので今はRailsを使ってできることに集中していいとのことでした。
言われてみると確かにその通りなのですが、ネットとかで「Railsは魔法の力すぎてRubyが理解できてなくてもいろいろ作れちゃうからヤバい」だのなんだの見かけると「どこまで理解できていればいいんだろう」とか考えちゃうのですよね。笑

私の場合、限られた時間の中でいかに効率よく勉強していくかが大事だと思っているので、いずれやらなきゃいけないことでもいまやるべきことと時が来たらやればいいことをしっかり見極めて勉強を進めていきたいなと思いました。

Railsが今何をやっているのか？！を知りたい

コードを書いている時、「この変数の中身ってここでは何が入っているんだ？」とか確かめたくなる時があったりしますよね。
そういう時に便利なのが、pry-railsというgemでこれで処理を止めて中身を確認、ということができるようになるそうで、これは覚えておいてねとのこと。
調べたら下記のページが非常にわかりやすそうでした。

ruby-rails.hatenadiary.com

後々自分でオリジナルアプリを作っていく際には必要な機能だと思いましたので、とりあえず備忘録として残しておきます。