Rのつく財団入り口

元はTRPG系のWebサイトの入り口だったブログです。最近のIT本の感想など。

【感想】Ruby on Rails 5アプリケーションプログラミング

最新のRails5をまるっと網羅した最新リファレンス本

 Ruby界隈で名高いRailsの解説本。Rails4版が2014年刊行、Rails5版の本書が2017/4月刊行でおそらく事実上最新の本、電子書籍版もあります。
 環境構築からMVC各層のコマンド、応用まで、主要機能が一式まるごと載っていてリファレンス本として使えます。VIEW部分の描画に使うビューヘルパー各種メソッドやActiveRecordの各種メソッドなどなど、オプションまでかなり丁寧に解説してある印象です。

Ruby on Rails 5アプリケーションプログラミング

Ruby on Rails 5アプリケーションプログラミング

 同時期に出たRails5の本ですと2016年12月の『Ruby on Rails 5 超入門』もあります。こちらはよりプログラム未経験の人にもフォーカスしてカラーページや画面キャプチャを多くして分かりやすそうですが、コード例などが一部Ruby/Railsのお作法に従っていなかったり不適切だという話をよくネットで見るので、開発経験者レベルの人には本書の方がお勧めのような。

Ruby on Rails 5 超入門

Ruby on Rails 5 超入門

2016年11月の『はじめての「Ruby on Rails」5』もありますがより初心者向けのようなので、経験者が選ぶなら本書か超入門でしょう。

はじめての「Ruby on Rails」5 (I・O BOOKS)

はじめての「Ruby on Rails」5 (I・O BOOKS)

 Rails5が上記3冊、Rails4に戻ると、『パーフェクト Ruby on Rails』や『実践Ruby on Rails 4 現場のプロから学ぶ本格Webプログラミング』など、おすすめ本によく名が上がる本がいろいろ出てきます。

 僕は幾つかの本やネットの情報に触発されてちょっと触りつつ、Rubyを普段使う機会はまだないので概要や動静の把握のため、他言語のフレームワークとの比較の為に読んだのですが、他言語開発者からみるとこの本でもう十分な内容でした。

Web Application Frameworkのカタチ

 よくプログラミング学習サイトや学生・若手向けの転職サイトなどでも人気、時として必要以上にもてはやされたり若干盲目的な持ち上げ方をされている感もあるRails
 一式読んだ感想としては中身に別に革新的なところはなく、MVCパターンの原則やActiveRecordの採用、開発側のコード量の削減を図った、実直、堅実堅牢、よく造られたフレームワークでした。(というか、世の中に突飛なWebサービスはあってもそれらを作るためのWebアプリケーションフレームワーク自体で突飛なものって普通ないですね)
 以前にPHP言語のフレームワークを何種か調べたことがあるのですが、面白いことに主要FWはだいたいみんな、何らかの形でRailsをリスペクトしたような似た構成なんですね。ビュー層はテンプレートを使ってコントローラ層から変数の値渡し、HTML要素の生成や入力チェック処理はビュー層に書いたりコントローラ層でメソッド群用意、そしてDBアクセスはPHPでもみなActiveRecordパターンでした。
 さらにMicrosoftASP.NET がWeb Formsに代わる新しいアーキテクチャとして打ち出したASP.NET MVCも、ビュー層周りはほとんどパクリもといRailsと同じようなアーキテクチャです。
 今はSPAとかMVVMモデルなど新しい流れも幾つかありますが、やはりWebアプリケーションのフレームワークは進化を突き詰めるとだいたい似たような完成形になるのだなと思いました。

余談:エンタープライズなアプリケーションへのRailsの応用方法

 さて拙者は普段はRailsでさっと作れちゃうような小規模アプリケーションではなく、よりエンタープライズな大きいアプリケーションが群生している領域に生息しています。
 画面の背後にはRDBが必ずいてテーブルは数十個、何かの検索画面を作ったらSQLでマスタテーブル各種から一緒に名前を引いて結合や副問い合わせは当たり前、画面のテキストボックスやセレクトボックスで決まる条件の組み合わせによって検索SQLが動的に変更されることもありえるような領域、SQLをまったく考えずに検索画面を開発してN+1問題とは一体何事ぞ!的な側の世界です。

 Railsの入門サイトやチュートリアルをかじってみたりネット上の各種情報リソースを見ていつも思ったのが、「確かにActiveRecordパターンはお手軽だけど、リレーションが複雑でテーブル数の多いRDBが控えてるような大規模なシステムにはどう適用するんだろう?」という話。
 実務で使っていないなりに想像したのは以下のような感じです。

●モデルクラスの種類を分ける
  • 例えば顧客のCustomersテーブルだったら.、ActiveRecord::ConnectionAdapters::DatabaseStatementsを使うなどしてSQLを生成・直接実行するCustomerFinderみたいなクラスを作り、一覧検索画面の複雑な検索だけはこちらから行う。
  • 詳細画面表示のようなidで一意になる1レコードの検索、そして挿入/更新/削除はふつうの class Customer < ActiveRecord::Base で行い、トランザクションRailsに任せる。
●大規模アプリの分割手法
  • ネットの情報で拝見したのは、まずRubyの持つモジュール機能で処理を外だしにする手法。
  • そしてコントローラ層とモデル層の間にレイヤーをもうひとつ設ける手法。サービス層とか。
    (PHP界隈で海外で一番ホットなフレームワーク、Laravelなんかもこれができるようになっています)

 こんな感じなのですが、実際のところはどうなのでしょうね。リアルで身の回りにいないのでよく分からないのですが、いつか機会があったらRubyistな方々に伺いたいなあ。とちょっと思っています。ヽ(´ー`)ノ