cypher256's blog

Pleiades とか作った

SAStruts が拡張性に乏しい？

SAStruts

ユースケース毎のクラスで各実行メソッド毎にURLが決まるので、共通処理が書けない。ログインチェック処理とか。（未ログインだったらどこかのページにリダイレクトするとか）ここらへんは拡張に乏しい。

2008-09-06

方法は色々あると思いますが、例えば、PreProcessor の role を処理している部分をオーバーライドすれば、なんとでもできる気がします。URL やパス、パラメーターで判断したり、それがあれな場合は、@LoginRedirect(action = "/hoge") アノテーションみたいなのを作ってアクションで明示的に指定するとか。でもアノテーションはメソッド呼び出しのように、直接処理を追えないので開発者はみんな嫌いですけど。たぶん。特に俺々アノテーションは。

関連することとして、前のプロジェクトでは AP サーバの BASIC 認証 (JDBC レルム) 機能を使用しましたが、下記の問題がありました。

  1. ログイン ID で検索し、結果をパスワードと照合するため、削除フラグなどが使えない
  2. 直接アクセスできないページは結局、自分で制御しなければならない


1 は AP サーバにより動きが異なるかもしれません。今考えると条件で絞ったビューにすれば良かっただけかもしれません。2 はどんなシステムでも機能遷移の途中にアクセスされては困るのであると思います。今回、新しいプロジェクトでまた SAStruts で開発中で、role 処理をオーバーライドして少しコードを追加して使っています。何かとらくちんです。@Execute アノテーションの roles 属性をここで参照し、適当に処理するようにしたと思います。

Rails の暗黒面

Rails SAStruts

ただ、Railsの中心的な考えであるConvention Over Configuration(CoC)は、強力だけど、暗黒面も強いと思うんだよね。一見簡単に見えるけど、ちゃんとしたアプリケーションを作ろうとしたら、かなり踏み込んだことまで知らないと、使いこなせない。

バージョンアップが早いので、直ぐに知識が陳腐化するだけでなく、前動いていた機能が動かなくなってしまうこともそれなりにある。

Railsの暗黒面とSeasar2の脱CoC - yvsu pron. yas

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

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


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

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

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


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

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

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