N2 ToolBox(跡地)

跡地です。引っ越しました。http://d.hatena.ne.jp/nosen

Strutsとの違い2

2004-05-20 00:36:03 | オープンソース
引続き、Strutsとの違いです。

3. ActionFormが、ない
WebWork/XWorkには、StrutsでいうところのActionFormにあたるものがありません。では、HTTPリクエストのパラメータをどうやって受け取るのかというと、昨日の話の通りActionがリクエスト毎にインスタンス化されるというのがミソで、Actionのプロパティに設定されてしまいます。なので、ActionFormにあたるものがない、というよりもActionFormとActionが一体化しているというほうがしっくりきますね。

4. 前処理/後処理
StrutsではActionに対して共通の前処理、後処理を設定しようとすると、Actionのクラス階層を形成して共通処理をスーパークラスにもっていく必要がありました。
これに対してWebWork/XWorkではServletFilterのようなChain Of Responsibilityの形をとる"Intercepter"というコンポーネントによってActionの前処理、後処理を行います。Interceptorのチェーンの構成は設定によってActionごとに変更することができるので、とても便利です。WebWork/XWorkではリクエストパラメータの検証やActionのプロパティへの設定もInterceptorとして実装されています。

細かいことをいえばいろいろあるのでしょうが、ざっと目についた違いはこんなところでしょうか。こういう風に書くと、なにかStrutsに恨みでもあるのかと思われそうですが、そんなことはありません。単に私がStrutsと比較しながら勉強した方が分かりやすかっただけなので、誤解なきようお願いします。
まあWebWorkの方が後発なのですし、きれいな作りになっているのは当然といえば当然ですよね。。。それもこれもStrutsという偉大な先輩あっての成果なのではないでしょうか。
なお、昨日と今日かいた内容は以下のページを参考にしています。

WebWork vs Struts

そろそろ実際にWebWorkを使って、何か動くコードを書いて行きたいと思います。

最新の画像もっと見る

3 コメント

コメント日が  古い順  |   新しい順
Unknown (kimuma)
2004-05-20 01:33:43
strutsとの比較は勉強になりました。

XWorkのことも知らないので知識不足ですが、やっぱり後発だけに基本設計はよさそうですね。

難があるとしたらユーザ数が少ない分、情報が少ないとか完成度・品質がどうかとかそんな感じでしょうか。

使いやすさは?ですが、パラメータがActionのプロパティというのは面白い発想ですね。

検証がServletFilterのようにできるのはすっきりしていると思いますが、

参照整合性チェックなどDBアクセスが発生する複雑なものはビジネスロジックで実装しそうな気もしますし設計時に考慮が必要なことがいくつかありそう。

最近はStrutsの勢いがありすぎで若干気持ち悪い雰囲気を感じるので対抗馬ももっと強くなっていってほしいかも。

ん?Servletとの依存が低いとして、認証やセッションとのやりとりはどうしているんだろう?
返信する
WebWork2日本語Doc (kimuma)
2004-05-20 12:49:31
まだ作成中のようですがドキュメント日本語化を進めているサイトがありました。

http://bossa.mond.jp/webwork2/docs_ja/
返信する
Unknown (ikkoan)
2004-05-21 02:32:25
日本語ドキュメントの情報ありがとうございます!参考になります。

フレームワークっていくら良くできていても、開発者に知識があって、かつ信頼性が高くないと現場では採用できないですよね?

僕自身もまだ勉強しはじめなので、そのへんを検証しつつ、まわりの仲間に調べた内容を展開しつつ、って感じですね。たしかに設計の素性はよさそうなので、期待は持てると思います。

ちなみにセッションとのやりとりですが、ActionContextというクラスを経由するようです。ActionContext.getContext()でスレッドローカルなActionContextのインスタンスが返って来るので、あとはgetSession()で取得できるMapを操作すれば良いようです。未検証ですが。そのへんも含めて今後記事にしていきたいです。
返信する