ちょっと前になりますが、案件でDoma2.0を使ってみたのでその使い勝手とかをレポしてみます。
Welcome to Doma
http://doma.readthedocs.org/ja/stable/
以下、公式より抜粋。
Doma は Java のDBアクセスフレームワークです。
Doma 2 には以下の特徴があります。
・注釈処理を使用して コンパイル時 にコードの生成やコードの検証を行う
・データベース上のカラムの値を振る舞いを持った Java オブジェクトにマッピングできる
・2-way SQL と呼ばれる SQL テンプレートを利用できる
・Java 8 の java.time.LocalDate や java.util.Optional や java.util.stream.Stream を利用できる
・JRE 以外のライブラリへの依存が一切ない
ようはよくあるJavaのO/Rマッパーです。
これを採用した理由は結構単純で
・JRE 以外のライブラリへの依存が一切ない
・SQLをファイルですべて管理できる
・たまには違ったものを使ってみよう
という理由からでした。
使い方は公式が良くできているのでそちらを見てもらって、自分は使ってみてきになったところを以下列挙してみます。
#1. トランザクションのかけかた
@Test
public void testSelectByAge() {
TransactionManager tm = AppConfig.singleton().getTransactionManager();
tm.required(() -> {
List<Employee> employees = dao.selectByAge(35);
assertEquals(2, employees.size());
});
}
トランザクションはラムダ式で書くみたい。慣れてないと結構はまっちゃうかも。
例外がRuntimeしか投げられなくなってるので、その前提で例外処理を考えておく必要あり。
tm.required(() -> {
この間がトランザクション
});
#2. ロガー
公式より抜粋
ログ出力ライブラリへのアダプタ
JdbcLogger を getJdbcLogger メソッドで返してください。 JdbcLogger はデータベースアクセスに関するログを扱うインタフェースです。 実装クラスには次のものがあります。
org.seasar.doma.jdbc.UtilLoggingJdbcLogger
UtilLoggingJdbcLogger は java.util.logging のロガーを使用する実装で、 デフォルトで使用されます。
そう、java.util.loggingの実装です。
自分はSLF4Jとかのが好きなので、自前でロガーを用意しなくてはなりませんでした・・・。
package jp.co.opst.doma.logger;
import java.sql.SQLException;
import java.util.LinkedHashMap;
import java.util.Map;
import net.arnx.jsonic.JSON;
import org.seasar.doma.jdbc.JdbcLogger;
import org.seasar.doma.jdbc.Sql;
import org.seasar.doma.jdbc.SqlExecutionSkipCause;
import org.slf4j.Logger;
/**
* SLF4J向けJdbcLogger実装クラス。
*
*/
public class Slf4jJdbcLogger implements JdbcLogger {
/**
* Loggerインスタンス。
*/
protected Logger log;
/**
* コンストラクタ。
*
* @param log logger
*/
public Slf4jJdbcLogger(Logger log) {
this.log = log;
}
@Override
public void logDaoMethodEntering(String callerClassName,
String callerMethodName, Object... args) {
StringBuilder logMessage = new StringBuilder();
logMessage.append(callerClassName).append(" ");
logMessage.append(callerMethodName);
// argsは略
log.debug(logMessage.toString());
}
・・・
こんな感じ。公式で用意してくれるとうれしいんだけどなぁ～
#3. 検索結果をでOptionalを使うとき、Entityがイミュータブルである必要がある
public interface HogeDao {
@Select
Optional<Hoge> selectById(Integer id);
}
HogeテーブルについてのDaoは↑のような感じになる。
このとき 検索結果でOptionalを使いたいとき、HogeはイミュータブルなEntityクラスである必要があるとのこと。
・・・ということは、検索結果の一部を変更してUPDATEしたいってときは Entityのインスタンスを再度作る必要があるということ。
まぁ作ってしまえばよいのですが、更新の数が多いと結構大変でした。。。。
#最後に
とはいえ、Entityクラスの自動生成があったり、SQLファイルへの条件の書き方が直観的だったり、と自分としては結構好みでした。
機会があれば使ってみてくださいませませ。
でわでわ。