Rails の暗黒面 - cypher256's blog

ただ、Railsの中心的な考えであるConvention Over Configuration(CoC)は、強力だけど、暗黒面も強いと思うんだよね。一見簡単に見えるけど、ちゃんとしたアプリケーションを作ろうとしたら、かなり踏み込んだことまで知らないと、使いこなせない。
バージョンアップが早いので、直ぐに知識が陳腐化するだけでなく、前動いていた機能が動かなくなってしまうこともそれなりにある。
Railsの暗黒面とSeasar2の脱CoC - yvsu pron. yas

今丁度、Rails を使ってガシガシやってます。SAStruts ではありませんが、Java とも連携しています。Rails と Java フレームワークの違いは色々なとこに書かれてますが、SAStruts と比較して個人的に思うところを長所短所含めてざっくり (フレームワークだけでなく、言語仕様もごちゃまぜで言ってます)。ちなみにどちらかを貶したり、擁護する気はありません。

Rails の後方互換性のなさは死ぬ。仕様も情報もプラグインも。
Ruby も Rails もやっぱりコード量少ない。びっくりするぐらい多機能。
Rails に良くも悪くもフォームクラスはない。Java で言えばただの Map みたいな。
ActiveRecord のモデルの DB 更新検証機能が○。
Rails ってコントローラー変更するとサーバー再起動しないとだめなことが多い？

上記 2 については、動的言語ではない Java は到底太刀打ちできません。これは共通化とかコード自動生成とか、そういうレベルでなく、継承しないでクラスを好きに拡張できたり、実行時に動的にメソッドを生成したりを指しています。Java は存在しないメソッド呼び出しはコンパイルできないため (最低インターフェースが無ければ)、このあたりは実現できません。ただ、Ruby のこれは、デバッグ時に軽く死ねます。

上記 4 については、モデル更新時に検証しているのが、Java のフレームワークと違い良いとか書いている人がどっかにいましたが、これは単純にフォームクラスを持たない Rails では定型的なチェックは、ここでしかやりようがないだけな気がします。でも、レイヤーの責務とか言う気はありませんが、実際のシステムでの入力チェックはレイヤー単位が理想的です。

画面入力項目チェック
画面入力項目相関チェック
DB 整合性チェック (関連するレコードが存在するとか)
DB 物理属性チェック (桁数、not null とか)

SAStruts は 1、2 の一部、4 は入力チェックアノテーション、あとはアクションかサービス、Rails は 1、4 をモデルのチェック機構でを行い、あとはコントローラーかモデルのどちらかになっていると思います。今回 Rails を使用したプロジェクトでは DB メタ情報を元に DB 物理属性チェック機能付きのモデルのソースコードを静的に自動生成するようにしています。実行時に動的に DB メタ情報チェックのほうがかっこいいかもしれません。DB 物理属性のチェックって必要ですが、書くのはめんどくさいだけで面白くないですもんね。

S2JDBC の機能に DB 物理属性チェックが取り込まれると嬉しい気がします。でも、メッセージの伝播をどうするか、UTF-8 マルチバイトは、メッセージや項目名との紐付けは、バッチで使った場合は、とかで複雑化して CoC っぽくなるのも避けたいところです。

静的にコードを生成できるということはフレームワークに無駄があり、動的生成を多用するフレームワークは CoC 色が強くなりがち。前者は IDE の補完やチェック機能を享受する目的もありますが、静的であれ動的であれ、自動生成は少なければ少ないほど良い気がします。