Domaのポリシー - taediumの日記

Domaがどんなものかちょっと説明してみます。SQLの生成とJavaとのマッピングに関するポリシーはこんなです。

検索系のSQLはSQLファイルにマッピング、自動生成機能は用意しない。動的なSQLはSQLコメントで実現。
更新系のSQLはデフォルトで自動生成、SQLファイルにマッピングすることも可能。
Javaではリレーションシップを扱わない。結果セット1行をJavaのオブジェクトの1インスタンスにマッピング。

規約はほとんど使いません。Daoのメソッドには次のアノテーションのどれかを記述してもらうことになります。（今は最初の4つしか実装できていないけど）

@Select
@Insert
@Update
@Delete
@BatchInsert
@BatchUpdate
@BatchDelete
@Procedure
@Function

更新系でSQLファイルを使う場合は

@Insert(sqlFile = true)

とします。

フレームワークにまかせずDataSourceから自分で制御したい場合があるでしょう。その場合はこんな感じで書けます。

@Dao(config = MyConfig.class, implementedBy = EmpDao.AbstractEmpDao.class)
public interface EmpDao {

    @Select
    List<Emp> selectByName(StringDomain name);

    @Insert
    int insert(Emp emp);

    abstract class AbstractEmpDao extends DomaAbstractDao implements EmpDao {

        public AbstractEmpDao(Config config, DataSource dataSource) {
            super(config, dataSource);
        }

        @Override
        public List<Emp> selectByName(StringDomain name) {
            DataSource dataSource = getDataSource();
            ．．．
            return null;
        }
    }
}

何をしているかというと、ネストしたクラスで自分で制御したいメソッド（ここではselectByName）だけをオーバーライドしています。
aptで生成されるクラスの名前はEmpDao_のままで、オーバーライドしたコードが動くようになります。ですので、開発途中で変更が入っても、利用する側はこれまでどおりEmpDao_をnewして使えます。