S2DaoとS2JDBC
・S2JDBCは、どんな所がSAStrutsに最適化しているのか？
SAStruts + S2JDBC
Teeda + S2DAO
これがよく言われている黄金？コンビなのかもしれませんが
その理由は？と聞かれると、私のようなSeasar初心者は
返答に臆すると思います。
Teeda + S2Dao の組み合わせですが、Teedaの画面周りのデータ構造はフラットであり、フラットなSQLの結果セットであるS2Daoの2WaySQLとの相性が良いと考える人がいるかも知れません。
しかし、S2JDBCの機能はS2Daoの機能を包括しているので、Teeda + S2JDBCでも良いと個人的には考えています。
S2JDBCは「流れるようなインターフェース」のインパクトが強いためか、時々、勘違いされている人を見かけるのですが、S2JDBCでもS2Daoと同じ構文で2WaySQLを使うことができます。（しかも、S2JDBCの2WaySQLはS2Daoのものよりも地味に進化しています。）
さらに、全てのデータアクセス処理を2WaySQLで処理すると開発コストが高くなってしまうので、SQL自動生成機能を併用すると思います。2WaySQLとSQL自動生成機能については、排他関係ではなくて、使い分けの比率が大切です。（簡単なデータアクセスはSQL自動生成、複雑なデータアクセスは2WaySQLが基本。）そして、より生産性が高いSQL自動生成機能の適応範囲が増えることがトータルの生産性向上に繋がると考えています。
このように考えると、S2DaoのSQL自動生成機能よりもS2JDBCのSQL自動生成機能の方が圧倒的にパワフルなので、トータルの生産性はS2DaoよりもS2JDBCの方が高くなると考えています。
Teedaは大規模向きではないのか？
また、Teedaと比べるとどうなの？とか
Teedaは大規模向きではないのか？など
私のようなSeasar初心者には見えにくいと思います。
Teedaはとても先進的で優れたフレームワークだと思います。（私の周りのRailsな人も絶賛してました）
ただし、大規模開発となると実績や開発者集め、学習コスト、実行性能の面でSAStruts(Struts)と比べて不利に思えます。
さらに、非機能要件対策系の機能が豊富なのがTeedaの強みの１つですが、これについてはStrutsで培った非機能要件対策系のノウハウをSAStrutsにも持ち込みやすいためにTeedaの利点が薄れてしまうといった側面もあるかと思います。
SAStrutsはなぜ大規模開発に向いているのか？
最新プログラム技術を貪欲に習得する先進的ユーザー企業
先日、ある企業様向けにSeasar2の研修を行ってきました。
この企業は、SIerではありません。様々なインターネット関連のサービスを
手がけていますが、SIerにソフト開発を発注する立場のユーザー企業です。
この企業のすごいところは、Webアプリケーション開発の最先端の
プログラミング技術を普段プログラムを書かない担当者にも
組織的にプログラミング技術を学ばせている点です。
少し前に id:higayasuo さんのブログの
『元請けもきちんとプログラミングできるようになること』
というエントリが反響を呼んでいました。詳しくは以下をご覧ください。
プログラミングできない元請けがプログラム設計書をレビューするという矛盾
http://d.hatena.ne.jp/higayasuo/20080415/1208224902
このエントリのコメントやトラックバックからすると、
元請け企業のプログラミング技術不足の指摘は的を得ていると思います。
そんな中で、冒頭で紹介させて頂いたユーザー企業は元請SIerを飛び越して、
最先端のプログラミング技術を習得するといった行動を既に起こしています。
SI業界のオピニオンリーダー的な人の発言を超えた行動を
既に起こしているのだから素晴らしいです。
組織的に時間も予算も掛けて本腰入れて習得しようとしてるため、
とても強い企業体質を築けることが予想できます。
ソフトウェアの受託開発は、発注担当者の能力がプロジェクトの
成否に大きな影響を与えると私は考えてます。その上で発注担当者が
プログラム技術を習得しているということは、元請SIerとの共通言語が
できるために、ワンランク上のコミュニケーションが実現でき、
プロジェクト運営がスムーズになることが予想されます。
おそらく、こういった考えをこの先進的なユーザー企業の経営陣が
理解されているのだと思います。
このような勝ち組になりそうな先進的ユーザー企業に選ばれて
お付き合いする元請SIerはより一層プログラム技術を習得して、
さらなるプロフェッショナル性が求められることになりそうですね。
ps. ちなみに、このユーザ企業様に受けて頂いたSeasar2研修の内容は以下のとおりです。興味ある方は、ぜひ、どうぞ！
http://www.tafc.co.jp/seasar2_seminar0805.html
アクションフォームを使うべきか？使わないべきか？
そこでまた疑問なのですが・・・
SAStrutsのページでは、基本的にActionクラスにActionFormも同梱するのを推奨しているようですが、dewa様の図だと、DtoとしてActionFormを分離されていますよね。
これによるメリットはなんなのでしょうか？
メリットは以下の２点と考えています。
- ソースコードの可読性（メンテナンス性）の向上
- テストしやすくなる
逆に、デメリットとしては、若干生産性が落ちることだと考えています。
ちょっと長くなりますが、この結論に至ったプロセスについて説明します。
私も最初は、アクションだけで実装していたのですが、複雑なユースケースの場合にソースコードが肥大してきました。肥大化対策を起点として、紆余曲折を経て、以下のようにアクションとアクションフォームを分離した方が良いと考えるようになりました。
【その１】
アクションが持つプロパティを画面入出力項目とそれ以外に分離して、画面入出力項目をアクションフォームへ移すとソースコードの可読性（メンテナンス性）が良かった。（アクションフォームの責務は、対応するアクションと同じユースケースの画面入出力項目を扱うことと位置付けました。）
【その２】
画面入出力項目を扱うクラスに関連するデータ変換処理の責務を負わせる方が自然だと考えました。実際に、データ変換処理メソッドをアクションフォームに置くことで、アクションクラスの肥大化を抑えることができ、さらに、ソースコードがスッキリしました。
【その３】
特定のユースケースで使用する繰り返し項目用Dtoや検索条件Dtoなどをアクションフォームの内部クラスとして定義すると、責務面でも自然だし、ソースコードも複雑にならなかった。
【その４】
アクションに存在していたデータアクセス処理部分をテストしやすくするために、メソッド分割したが、入力データの流入経路がメソッド引数とプロパティの両方が指定できるために、入力用のテストデータをセットしにくかったので、データアクセス処理部分をサービスクラスへ移動しました。
すると、入力値はメソッド引数のみで定まるため、インターフェースがハッキリして、テストしやすくなりました。この際、アクションフォームの内部クラスとして定義した検索条件Dtoなどを積極的にサービスメソッドの引数に渡すようにします。（サービスは特定ユースケースのデータクラスに依存してしまうので、サービスの粒度もユースケースを想定しています。（※））
この実装方針は以下の問題点があることが分かっています。
- 若干の生産性の低下
- （内部クラスも含めて）作成するクラス数が増えてしまう
- ユースケース単位のデータクラスをセッションの扱いにくい（次のいずれかの方法）
- アクションフォーム自体をセッションスコープにする方法（個人的にはこの方式はイヤ）
- セッションスコープのDtoを別で作成して、アクションにDIする方法（本来であればアクションフォームの責務なのに、別の箇所で処理しなければならないので、設計的に美しくない。）
- 検証メソッドがアクションにしか置けない
- 画面入出力項目に関する責務については、すべてアクションフォームで処理したいところ。しかし、フレームワークの制約で、検証メソッドはアクションフォームに配置できない。（現行では、検証メソッドはアクションに配置します）
追記：
1.0.3-rc1 より、アクションフォームでも検証メソッドを記述できるようになります。
とは言いつつも、少し誤解を招いてしまいましたが、私はあらゆる状況で「アクションとアクションフォームの分離」が最適と主張している訳ではありません。『大は小を兼ねる』的な発想で比較的無難な[方針２]を紹介させて頂いたという訳です。実際には、状況に応じて使い分けるのが良いと思っています。これについては、以前に書いた以下のエントリをご覧ください。
「８割の簡単な処理」と「２割の複雑な処理」への対処方針
http://d.hatena.ne.jp/dewa/20080531#1212211267
アクションとアクションフォームを分離している方針は、上記のエントリで説明している[方針２]に相当します。
[方針２] ２割の複雑な処理にあわせる * 品質重視。ただし、簡単な処理の生産性は落ちる。
ちなみに、アクションフォームを作らずにアクションのみで勝負する場合は[方針１]です。そして、基本はアクションのみだけど、複雑なユースケースの場合にアクションとアクションフォームの両方を作る場合は[方針３]です。
[方針1]にしても[方針2]にしても、どこかで無理が出てきます。なので、簡単な箇所には簡単なアーキテクチャを適応して、複雑な箇所には複雑なアーキテクチャを適応する[方針3]が、本当は自分は一番理想だと考えています。（でも、こういう考え方って、なかなか受け入れて貰えないんだろうなぁ。）
SAStrutsはまだまだ新しいプロダクトなので、このあたりの定石は固まっていないので、他の人の意見も聞きたいところです。
※ ちなみに、SAStrutsのメイン開発者のid:higayasuo さんは、サービスの粒度はエンティティの方が良いと考えており、私と主張が異なっているので注意してください。アクションフォームも基本的には作成すべきではないと考えていらっしゃるようです。
アクションフォームの使用が推奨されるようになりました。
Firefox3
昨日、Firefox3が正式リリースされたのでインストールしてみました。
激速ですね。素晴らしい！キビキビしまくりです。
次世代ブラウザ Firefox
http://mozilla.jp/firefox/
今まで、WebブラウザはSafariを使っていたので、速さでは満足していました。でも「Googleツールバー」と「はてなバー」、「マウスゼスチャのプラグイン」が使えないことがやや不満でした。「Googleツールバー」で英単語にマウスフォーカスするとポップアップで日本語の意味を教えてくれる機能がないと、何気に英語の文章を読むのが辛かったんですよね〜。
SafariからFirefox3への移行において心残りなのは、Safariの美しいフォントから離れてしまうことです。
「Googleツールバー」以外のプラグインは、まだ確かめていませんが、これを機にメインで使うWebブラウザはFirefox3でいこうと思います。
