ひがやすを技術ブログ

電通国際情報サービスのプログラマ

DIの設定をJavaでその2

予想通り(?)、反応は、まさたかさんと太一と横田さんだけですね。太一は予想してなかったけど。もともと、Seasar2は設定ファイルを書かないので、あまりニーズはないのかもしれません。
後、DSLとしてJavaを使うのは、JavaDSLとしての記述力が弱いので、向いていないと思います。

AOPの使いどころ

そもそもAOPってそんなに使いどころあるでしょうか。

AOPは、使いどころありますよ。よく使うのをあげると

これらのAdviceは、ほとんどのシステムで有効だと思います。ログインチェックは、Servlet Filterでもできると思いますが、例外処理で元の画面に返すとか特定の画面に飛ばすとかFilterだとちょっとやりにくいですね。メソッドの呼出し毎にトレースログを取るとなるとAOP以外でやるのはちょっとめんどくさい。
また、Seasar2では、S2DaoのようにinterfaceにAOPを仕掛けて、実装コードを書かなくても良いようにする系のフレームワークが実装コード削減に大いに貢献しているので、AOPなしはちょっと考えられない感じです。

UujiとKuina-Daoの関係

UujiのCriteriaの仕様は、実はKuina-Daoとそっくりです。兄(Kuina-Dao)と弟(Uuji)の関係と言えるでしょう。KuinaDaoはS2Dao-CodeGenインスパイヤされたといっていた気がするので、S2Dao-CodeGenは、いとこのお兄さんなのかもしれません。
Uujiは、DBFluteにも似ているのではないかと思います。これは、久保さんの意見がかなり反映されているからです。
Uujiっていつできるの」って声が聞こえてきそうですが、当初よりかなり仕様を膨らませたので、リリースは、ゴールデンウィーク明けではないでしょうか。今のS2DaoDBFlute or S2Dao-CodeGenでも1:Nの機能を除く検索系のCriteriaの機能は使えるので、ぜひご利用ください。

updateAll


EmpDao#updateAll(Emp entity, EmpCriteria criteria);
updateAllは、複数の行を1回のSQLで更新するためのものです。組織替えがあって、deptIdが1の従業員を2に更新する必要があるとします。Javaのコードは次のようになります。

EmpCriteria criteria = new EmpCriteria();
criteria.setDeptId(1);
Emp entity = new Emp();
emp.setDeptId(2);
dao.updateAll(entity, criteria);
entityがupdateのset句にあたり、criteriaがwhere句に相当します。

EmpDao#deleteAll(EmpCriteria criteria);
も同様に考えれば直ぐに理解できるでしょう。

SQLの扱い

今度は、手動のSQLを使う場合です。
Uujiは、S2Daoと同様にクラス名_メソッド名.sqlのファイルがDaoのインターフェースと同じパッケージに置かれていたら自動的にそのSQLを適用します。強力なのは、関連もきちんとサポートできることです。例えば、次のSQLファイルとDaoがあるとします。


select * from emp left outer join dept where job = /*job*/'hoge' or dep_id = /*deptId*/1

List findAllByJobOrDeptId(String job, Long deptId);
Uujiは、SELECTリストが*なので、empのデータとその関連のdeptをつめたempのリストがかえります。WHERE句の条件には使うけど、結果にはdeptがいらない場合

select emp.* from emp left outer join dept where job = /*job*/'hoge' or dep_name = /*deptName*/'foo'

List findAllByJobOrDeptName(String job, String deptName);
のように書くことができます。結果をDTOマッピングしたい場合は、SELECTリストでASでDTOのプロパティ名を指定します。

class EmpDto {
private Long deptId;
private BigDecimal maxSal;
private BigDecimal minSal;
...
}

List findAllMaxSalAndMinSal();

select dept_id as deptId, max(sal) as maxSal, min(sal) as minSal
from emp group by dept_id

単純と簡単の狭間で。

シンプルであるということは,それだけで様々なメリットもたらす,とてもとても重要なものだと思います.
しかし,シンプルでさえあればそれでいいのかというと,必ずしもそうとはいえないのが難しいところ.

私は、シンプルなのが好きですね。ただ、私のポリシーは、「自分が書きたいものではなく、ユーザが欲しいものを提供する」なので、多くのユーザが望むものを提供したいと思っています。
でも、Seasar2はシンプルだと思うんだけどなぁ。リッチ(機能は豊富)かもしれないけど個々の機能(or クラス)は複雑ではなくシンプル(単純)。ユーザが使う上では、覚えることも実際に書かなければいけない手間もかからずシンプル(簡単)。実装は単純で、ユーザにとっては簡単というのは両立できると信じています。