Rails本読みおえて、、、
ちょっと前に、たらたら読んでいたのだが、ようやく読み終えた。
- 作者: 前田修吾
- 出版社/メーカー: オーム社
- 発売日: 2006/02/25
- メディア: 単行本（ソフトカバー）
- 購入: 2人 クリック: 109回
- この商品を含むブログ (207件) を見る
- Web アプリケーションの設計とか注意点とか、と
- データ(ERD)、業務領域(モデル)というあたりの作り方
Webアプリケーションの設計、注意点、それからプロセス構成とか
いままでぼくが知っているところは、サーバ側(といっても、メッセージング層とか、だいぶユーザーからは遠いところ)が中心でした。そんなわけで、Rails に限らず、Web の設計とか注意点とか、漠然としか知らなかったことを初めて一通り学んだと思います。
さらっと頭に残っていることはこんなところでしょうか。
- 破壊的操作は HTTP POSTで！(またはDELETE/PUT、GETじゃないやつね)
- セッションの配置の仕方
- httpサーバ、アプリプロセスの配置/構成 (の1つの方法)
最初のやつは、きっと Web 屋さんには当然なことなのかもしれませんが、それを警告として触れるだけではなく、フレームワークとしてサポートしてくれているところに Rails らしさを感じました。昔、Java で HelloWorldServlet を書いた時は、doPost を doGet に委譲して･･･、みたいなことをやっていたような。Struts とか Spring/Seasar2 まわりの Web アプリ系ライブラリがこのへんを Java でどう解決しているのかはちょっと気になるところですね。
2番目のセッションの配置については、3番目とも絡むのだけど、完全にアプリ処理プロセスの外部に置いてしまう、というのがキッパリしていて分かりやすい＆あとで制御しやすくて良いと思った。少々大きめのシステム開発では、外部ストレージがあるのは普通になってると思うし、小さく始めるときでもやりやすい(はず)。 Rails というか Ruby という意味では、DRb を使ったプロセス間でのデータ共有が面白いところでしょうか。1つ管理するプロセスが増えはするけど、負荷としてはファイルシステムじゃちょっとしんどいよね、でも面倒なことは嫌だ、って場合に手軽に使えるところがいいと思う。永続化は別問題だけど。
で、一番考えさせられたのは3番目のプロセス配置の問題です。あれ？大事なことは最初に書け！って習ったような、、、(〃_ 〃)ゞ
Rails の Wiki やブログを見ていると、多く出てくるのが、lighttpd + mod_fastcgi + FastCGI の構成。最初は、Ruby がユーザースレッド(OSライブラリスレッドでは無い)で動作するスレッドモデルを採用しているための、逃げの手かと思っていた。でも、色々と考えていくうちに、もしかしたらとっても良い構成なのではないかと思い始めてきた。長くなりそうなので、後で書く。
データ(ERD)、業務領域(モデル)というあたりの作り方といったこと
本の中で、「David 曰く」の囲み記事で DHH 自身が考え方を言葉に落としている(脳内ぶちまけ)。その中で、何度か ERD や業務領域*1に触れています。一つは
PK は物理的な数値にしておく
これは、前にも書いたしそういうこと。先週同僚から聞いた話では、楽々ERDレッスン (CodeZine BOOKS)
で、羽生章洋さんも同じことを書いているそうだ。そのうち読もう。
もう一つ、刺激されたことは、これ
単純な関連テーブルをどしどし作るのではなく、
可能な限りモデル化する。
そこに、豊かな振る舞いを追加することで、
ロジックが整理・カプセル化され見通しがよくなる
最後あたりの記憶が曖昧だけど、言ってることは大体あっているはず、たぶん。
SQL でいっぱい JOIN しまくって、フラグとかで条件分岐しまくって、、、みたいなコントローラ(アクションというべきか)を見飽きたところで、こういうことをズバッといわれると鳥肌が立つ。「業務アプリでオブジェクト指向っぽいモデルなんて無理だって、ワッハッハ〜」ということを何度も聞いたことがある。でも、少なくとも小さな開発であれば(弱気)、それは無理ではないはず。と実践の機会が無いまま、空想の世界だけで思っていた。出来るのか？本当に出来るのか？非常に気になる。
今、お仕事では、あるプロセス(群)の管理画面を、Webアプリで作ろう、ということをしている。まだプロトタイプの域を出ていないのだが、出来る限りモデル層を使うように意識している。アクションは、モデルの繋ぎあわせと、必要なエラーハンドリングのみにしたいと。
