About

ドキュメント

プロジェクト文書

Built by Maven

概要

Domaは、より扱いやすいS2Daoを目指しています。 S2Daoの良いアイデアや機能は受け継ぎつつも、扱いにくかったりプログラミングミスにつながりやすかったりする点については改善を試みています。 さらに、S2Daoにはない新しい機能も提供します。

Domaは、S2Daoの次のアイデアや機能を受け継いでいます。

一方、Domaは、S2Daoの次の点を改善しています。

さらに、Domaは、新しく次のような機能を提供します。

  • コンパイル時のソースコード生成
  • コンパイル時の規約チェック
  • コンパイル時のSQL存在チェック
  • コンパイル時のSQLコメント文法チェック
  • ページング用SQLの自動生成
  • 悲観的排他制御用SQLの自動生成
  • アプリ固有の値型への対応
  • JDBC 4.0サポート

開発にあたっては、S2Daoのほかに、 S2JDBCHibernateも参考にしています。

S2Daoから受け継いだアイデアや機能

DAOパターン

DomaではS2Daoと同様にDAOパターンを採用しています。

DAOパターンを採用するのは、次のような利点があるからです。

  • データアクセスの箇所を特定しやすい
  • データアクセス処理をカプセル化できる(SQLの自動生成処理をJDBCを直接利用した処理に変更しても利用側プログラムに影響を与えない)
  • テストをしやすい(モックを作成しやすい)

2 Way SQL

S2Daoでは、外部ファイルに記述したSQLを、Javaとマッピングした形でフレームワークの一部として取り込むことも、単独でSQLツール上で実行することも可能としています(2 Way SQL)。

Domaでは、このアイデアをそのまま採用しています。ただし、マッピングルールやSQLコメントの用い方については変更を加えています。 2 Way SQLは、フレームワークで扱うSQLを単独でテストしたり、Java開発者とSQL作成者の作業を分離したりするのに非常に有効な方法です。

S2Daoからの改善点

Seasar2への依存

S2Daoを利用するには、Seasar2のライブラリが必須です

一方、Domaでは、Seasar2への依存が一切ありません。このため、Spring FrameworkGuiceといったSeasar2以外のDIコンテナと組み合わせたり、単独で利用したりしやすくなっています。 Domaはdoma-x.x.x.jarという単独のjarファイルのみで動作します。

AOPの利用

S2Daoでは、実行時にDaoのインタフェースにAOPを適用することで動作します。

一方、Domaでは、コンパイル時にaptでインタフェースから実装クラスをソースコードとして生成し、実行時には生成されたソースコードに対応する実装クラスを使用します。

AOPは便利な機能ですが、挙動が把握しにくかったりデバッグがしにくかったりといった問題点があります。 Domaではこれらの問題点を避けるため、AOPではなくaptによるコード生成を利用しています。

ただし、S2DaoであれDomaであれ、アプリケーション開発者が作成するのはインタフェースのみという点は同じです。

命名規約

S2Daoでは、たとえば、Daoのメソッド名が「update」で始まる場合そのメソッドはUPDATE文を発行するメソッドである、といった命名規約を持っています。

一方、Domaでは、暗黙的な命名規約ではなく、アノテーションを採用しています。たとえば、UPDATE文を発行するメソッドには@Updateといったアノテーションを使用します。 Domaでは、暗黙的な命名規約を排しアノテーションを利用することで意図をより明確にプログラムコード上に表し、挙動をわかりやすくしています。

JavaとSQLの不十分な分離

S2Daoでは、SQLを外部ファイルに記述することを認める一方、DaoのメソッドにアノテーションでSQL全体やSQLの一部を記述することも認めています。 しかし、アノテーションでSQLを記述するのは、JavaとSQLの分離が不十分です。

Domaでは、DaoのメソッドにアノテーションでSQLの全体や一部を記述することを認めません。 JavaのコードにSQLを記述することは、アプリケーションの保守性を損ねるからです。 SQLを記述する場合は、外部ファイルを使用する必要があります。

SQLコメントの間違いやすい文法

S2Daoでは、SQLに含まれたSQLコメントの前後にスペースがあるかどうかなど非常に細かく間違いやすい違いがフレームワークの挙動を左右します。また、間違いが含まれていた場合のエラーメッセージもわかりにくいものです。

Domaでは、文法を見直し、間違いにくいようにしています。またコンパイル時にaptで検証することで、間違いがあっても早期にエラーを検出しています。

JDBCを直接利用する方法

S2Daoでは、Daoの特定のメソッドでJDBCを直接利用するには、インタフェースの実装クラスを作成しメソッドをオーバーライドします。 この方法では、AOPを適用するクラスを変更する必要があります。

Domaでは、@Delegateというアノテーションを使って、JDBCを直接利用する処理を別クラスに委譲できます。 この方法は、クラス階層に変更を加えないためより柔軟です。

詳細は、デリゲート定義を参照してください。

DaoのメソッドとSQLファイルのマッピング

S2Daoでは、SQLファイルをDaoと同じパッケージに配置しなければいけません。 この仕様では、異なるDaoが同じパッケージにあると同じ階層に異なるDaoのSQLファイルが混在することになり、管理が難しくなります。

Domaでは、Daoごとに異なるディレクトリでSQLファイルを管理する仕様になっています。

詳細は、SQLファイルを参照してください。

DaoのメソッドのパラメータとSQLファイル上のバインド変数コメントのマッピング

S2Daoでは、メソッドのパラメータがSQLファイル内のバインド変数コメントで参照できるようにArgumentsアノテーションを使用してパラメータごとに名前をつける必要があります。

Domaでは、Argumentsアノテーションに相当するものは不要です。aptによりメソッドのパラメータ名をそのまま使用できるからです。

Daoの初期化コスト

S2Daoでは、Daoの最初のアクセス時に、Daoのメタ情報を作成するための初期化コストがかかっています。 ここでのメタ情報とは、どのメソッドがどのCRUDに相当するのか、そのメソッドではSQLを自動生成するのかSQLファイルにマッピングするのかといった情報です。

Domaでは、コンパイル時にメタ情報をソースコードで表現し、実行時にはそのソースコードに対応するバイトコードを実行するため、そのようなコストがありません。