Railsガイドを読んで気になる所を復習

Railsチュートリアルも終わり、アプリを1本書こうと思っています。

まずは手始めにRailsガイドを斜め読みしました。

 

前回も書いたとおり、Railsチュートリアルを終わった直後の印象としては、フレームワーク全体を支配している(ようにみえる)、「リソース=モデル?」の存在が気になっていました。

例えばRailsチュートリアルを読んでいくと、「User」や「Micropost」や「Relationship」というモデルが登場しています。そしてこれらのモデルに合うように、URLも、画面インターフェイスも作られているようにみえてきます。(もちろんこれは正確ではないと思います。)

 

もし、「モデル」に画面もURLも引っ張られてしまうようであれば、「モデル」設計には、「データベースのテーブル」設計の要素以外にも、画面遷移、UI設計の要素まで詰め込まなければならないのでは?と思っていました。

 

そこでまずはRailsガイドで上記のような設計にハネそう*1な主だったところの調査です。

https://railsguides.jp/

 

 

結論としては、「懸念していた点」については「問題ない」という確認ができ、一般的なアプリの設計で進められそうだという確証が持てました。

 

 

 

まずは、URLに直結するルーティングのページです。

トップページにルーティングについて書かれたページへのリンクがありますね。

 

最初の「1.2章」までで私の不安は払しょくされました。resourcesを使って定義していたルーティングは、ただの省略形だったのですね。これなら、いくらでもやりようがあります。そして何より、サンプルなどでは「Book」や「User」のようなモデルにかかっているように見えて、しっかりと「Controller」を「resources」として認識していますよね。 (最終的にControllerのメソッドにマッピングされなければならないのは認識していますが、resourcesがそもそもControllerだったので安心したのです)

 

 そしてもう一つは、Formです。Railsチュートリアルでユーザページにmicropostの一覧を描画しているので、1コントローラ当たり(≒1ページあたり)に複数のモデルからデータを集めて表示することはできる確証がありました。

しかしながら、登録画面のほうではform_for(@user)となっているように、1コンローラ当たりに1モデルしか扱えないのでは?と思えてきます。そこでいろいろ調査。

 

 Railsガイドによればform_tagのような別のヘルパーがあり、こちらでは、フレームワークの皮をはいで、ほぼ純粋なhtmlフォームに近い感覚で使えそうです。

しかしこれを使うと、更新ページや削除ページに「現状データ」をマッピングする必要があり、やはり手間です。

 

ViewとControllerの間で受け渡すための「モデル」を定義する、つまり データベース上のテーブルと一致しないモデルを定義できれば良いのだということに思い至り・・。

 

https://railsguides.jp/active_model_basics.html

 

 ActiveModel::Modelを追加すると、Action PackやAction Viewと連携する機能をすぐに使えるようになります。

 

 あ、これですね。

 

下記のようなことが確認できました。

  • URLやルーティングはモデルとは別々にきることができる。Controllerとそのメソッドに機械的に割り振る定義(resources)もできるし、それさえも手動マッピングできる。
  • Controller→Viewへはもちろん、View→Controllerについてモデルに縛られない。View=Modelになるように、ActiveModelというライブラリを使って定義できる

あ~よかったぜヾ(*´∀`*)ノ 

 

 

次回の更新予定

・ActiveModelは、generate modelで作った≒データベーステーブルのDaoに近い「ApplicationRecord」とは別なので、別ディレクトリに配置する設定

・設計時に書いた図と、最初の「1ページ」

を乗せるつもりです。 基本、これをこのアプリでのパターンとして他画面も実装していきます。

 

*1:そういえばハネそうというのは業界用語なんでしょうか?影響が出る、だいたいはネガティブな意味ですね