SAStruts を選んだ 5 つの理由 - アーキテクチャ

これは私がその都度、俺々フレームワークでやってきた理想形でした。もちろん、すべての問題領域でカバーできるとは思いませんが、私が今まで携わったシステムでは適用しても問題にならないと思います。その昔、エラい人たちが語ってきたものとすべて真逆ですが、そういう方はやっぱり SAStruts は向かないと思います。

トランザクション境界が広い

その昔 Session-in-view パターンというのがありました。でも、トランザクション境界は狭ければ狭いほど良い、とかビュー層でトランザクション開始とかバカじゃね？ サービス層だろ？ というのもよく見かけました。いや狭かったらめんどくさいでしょ。というか広いと問題になることを実際に検証せずに言っている人も多かったと思いますし、そういうとこだけ何とかすればいいと思います。各開発者がトランザクション境界や属性を決めるって無駄すぎです。

責務に応じたレイヤー分けがない

何か詰めなおして、次のレイヤー呼び出すだけっていうのを良くみかけました。本当は疎結合で再利用可能になるのが理想的ですが、これはレイヤー分けを主張する人の夢物語でしかありませんでした。現実はほとんどコピペして名前変えるだけのクラスが大量生産され、設定ファイル地獄に陥っているところがほとんどではないでしょうか？

public フィールド

これは、ちょっと私がいやらしいかもしれないのですが、今まで開発者に対して質問してきました。なぜ setter/getter を作るの？って。回答はカプセル化しないとだめだから、とか。突っ込んでいくと最終的に、そう習ったとか、みんなそう言ってるもん、とか。いえ、利点はありますが、少なくとも DTO に関しては public フィールドの長所がカプセル化の長所をはるかに凌駕します。実際、自分でフレームワークを作るとライブラリやツールのサポートの問題にぶつかるのですが、今回は SAStruts と Beans がそれをやってくれています。

ビュー

誤解をおそれずに言えば、コンポーネントツリーとかいう .net のコントロールツリーの劣化版や Swing ライクなものもありますが、これは開発メンバ全員がこういうの大好きっていう場合は良いと思います。SAStruts は JSTL や Struts タグを除くと s:form とファンクションちょこっとっていう潔さが良いです。HTML ベースのものもいいですが、それはそれで結構コード量が増えますしね。

Struts 1.2.9 ベース

これは 1.3 や 2.0 ではないところです。1.2.9 は完全に枯れていて、1.3 や 2.0 は中身は別もので、枯れていません。同じ名前を名乗っていいの？というぐらいです。