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っていつできるの」って声が聞こえてきそうですが、当初よりかなり仕様を膨らませたので、リリースは、ゴールデンウィーク明けではないでしょうか。今のS2DaoとDBFlute or S2Dao-CodeGenでも1:Nの機能を除く検索系のCriteriaの機能は使えるので、ぜひご利用ください。
updateAll
updateAllは、複数の行を1回のSQLで更新するためのものです。組織替えがあって、deptIdが1の従業員を2に更新する必要があるとします。Javaのコードは次のようになります。
EmpDao#updateAll(Emp entity, EmpCriteria criteria);
entityがupdateのset句にあたり、criteriaがwhere句に相当します。
EmpCriteria criteria = new EmpCriteria();
criteria.setDeptId(1);
Emp entity = new Emp();
emp.setDeptId(2);
dao.updateAll(entity, criteria);
も同様に考えれば直ぐに理解できるでしょう。
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
Uujiは、SELECTリストが*なので、empのデータとその関連のdeptをつめたempのリストがかえります。WHERE句の条件には使うけど、結果にはdeptがいらない場合
ListfindAllByJobOrDeptId(String job, Long deptId);
select emp.* from emp left outer join dept where job = /*job*/'hoge' or dep_name = /*deptName*/'foo'
のように書くことができます。結果をDTOにマッピングしたい場合は、SELECTリストでASでDTOのプロパティ名を指定します。
ListfindAllByJobOrDeptName(String job, String deptName);
class EmpDto {
private Long deptId;
private BigDecimal maxSal;
private BigDecimal minSal;
...
}
ListfindAllMaxSalAndMinSal();
select dept_id as deptId, max(sal) as maxSal, min(sal) as minSal
from emp group by dept_id
単純と簡単の狭間で。
シンプルであるということは,それだけで様々なメリットもたらす,とてもとても重要なものだと思います.
しかし,シンプルでさえあればそれでいいのかというと,必ずしもそうとはいえないのが難しいところ.
私は、シンプルなのが好きですね。ただ、私のポリシーは、「自分が書きたいものではなく、ユーザが欲しいものを提供する」なので、多くのユーザが望むものを提供したいと思っています。
でも、Seasar2はシンプルだと思うんだけどなぁ。リッチ(機能は豊富)かもしれないけど個々の機能(or クラス)は複雑ではなくシンプル(単純)。ユーザが使う上では、覚えることも実際に書かなければいけない手間もかからずシンプル(簡単)。実装は単純で、ユーザにとっては簡単というのは両立できると信じています。