はじめに
前回は、DBFluteの概要を紹介致しました。今回からは、実行環境を構築し、実際に利用しながらどんな機能があるのかを見ていきましょう。
DBFluteの環境構築
環境の前提
以下の環境が利用されるPC上に揃っていることを前提とさせて頂きます。
- Java-5.0(以上)の実行環境
- Apache Ant-1.7.0(以上)の実行環境
- Eclipse-3.2(以上) ※今回は3.3を利用
データベースに関しては、今回はサービス起動の必要の無いH2データベースを利用します。
テーブル構造は前回の記事の最初に紹介した「例題で利用するテーブル構造」を利用します。
プラグインのインストール{Dolteng/EMecha}
まず、必要なプラグインをインストールしましょう。
DBFluteの環境を構築するためには、Eclipse上で「Java Project」が存在することが前提です。
手動で作成されても構いませんが、今回は、Seasarファウンデーションが提供する「Dolteng」を利用してプロジェクトを作成します。
また、DBFluteの環境構築支援として「EMecha(イーメカ)」を利用します。EMechaは、DBFluteが提供するEclipseプラグインです。
以下のような手順でインストールします。
- メニューにて「ヘルプ」-「ソフトウェア更新」-「検索とインストール」を選択
- フィーチャーの更新画面にて「インストールする新規フィーチャーを検索」-「次へ」を選択
- 更新アクセス先サイト画面にて「新規リモート・サイト」を選択
- ローカルサイトの編集ダイアログにて以下を入力してOKを選択(図1)
- Seasar-3.3にチェックを付けて「完了」を選択
- 更新画面にて「Seasar-3.3」-「Dolteng」を選択[2]
- 更新画面にて「Seasar-3.3」-「EMecha」を選択
- 次へを選択し、フィーチャー・ライセンスに同意しさらに次へ
- 終了を選択
プロジェクト作成{Dolteng利用}
プラグインの準備ができたので、いよいよEclipseのプロジェクトを作りましょう(図2)。
- メニューにて「新規」-「プロジェクト」を選択
- ウィザード選択画面にて「Chura Project」を選択
- プロジェクト名とルートパッケージを入力
- ロジェクト名 : dbflute-gihyojp-example
- ルートパッケージ : org.seasar.dbflute.example.gihyojp
- プロジェクトタイプで「Super Agile(Teeda + S2Dao)」を選択
- 完了(プロジェクトが作成される)
すると、「dbflute-gihyojp-example」というEclipseのプロジェクトが作成されます(図3)。
環境構築手順{EMecha利用}
Eclipseのプロジェクトの作成できたので、そのプロジェクトにDBFluteクライアント環境を作成します。EMechaを利用すると、クライアント環境の作成と同時にDBFluteのモジュール本体の設置も行うことができます。
EMechaのDBFluteクライアント作成画面を利用します(図4)。
- Doltengで作成したプロジェクト「dbflute-gihyojp-example」を選択(パッケージエクスプローラ上にて)
- メニューにて「新規」-「その他」を選択
- ウィザード選択画面にて「DBFlute Client Directory」を選択
- 画面にて以下の入力項目を入力
項目 | 入力値 |
Container Name | dbflute-gihyojp-example ※自動設定 |
Project | exampledb |
Database | h2 ※リストボックスにて選択 |
Target Language | java |
Target Container | seasar |
Package Base | org.seasar.dbflute.example.gihyojp.dbflute |
Driver | org.h2.Driver ※「Database」の選択次第で自動設定 |
Url | jdbc:h2:file:../src/main/resources/exampledb/exampledb |
Schema | (空) |
User | sa |
Password | (空) |
- 画面にて「Latest Version (From WebSite)」ボタンを選択
- 画面にて「Download DBFlute」ボタンを選択 ※注:ダウンロードに多少時間が掛かります。
- 終了を選択
- プロジェクト「dbflute-gihyojp-example」を選択して最新化(F5)
すると、dbflute-gihyojp-example配下に「dbflute_exampledb」と「mydbflute」が作成されます(図5)。
それぞれの入力項目の概要説明は以下の通りです。
項目 | 概要 |
Project | DBFluteクライアントの任意のプロジェクト名。通常はDBの名称やアプリの名称などを入れる。 |
Database | 利用するデータベースの種別。リストボックスにて選択。 |
Target Language | 自動生成するクラスの言語。リストボックスにて選択。 |
Target Container | 利用するDIコンテナ。リストボックスにて選択 |
Package Base | 自動生成するクラスのパッケージを指定。通常はルートパッケージ + 'dbflute'。 |
Driver | DB接続で利用するドライバ名。項目「Database」が選択されると自動的にドライバ名が設定される。 |
Url | DB接続URL。 |
Schema | DB接続スキーマ。データベースによっては指定無しでもOK。 |
User | DB接続ユーザ。 |
Password | DB接続パスワード。 |
S2Dao | 利用するS2Daoのバージョン。通常は「Latest Version (From WebSite)」で取得した値を設定。 |
DBFlute | 利用するDBFluteのバージョン。通常は「Latest Version (From WebSite)」で取得した値を設定。 |
執筆時点でのEMechaのバージョンは「0.1.0」で、まだまだ開発中のステータスです。今後細かい部分での改善や他の設定項目への対応など環境構築支援を予定しています。
DBFluteにてテーブルスキーマ作成
さて、DBFluteの準備が整いました。今回のサンプルで利用するテーブルスキーマを作成します。
テーブルスキーマの作成方法はどうようにしても構いませんが、DBFluteではReplaceSchemaというタスクを提供し、テーブルの初期作成・再作成・テストデータ投入を簡単に実現できるようにしています。
DDL文は、次のリンクからダウンロードすることができます。
ダウンロードしたDDL文を「dbflute_exampledb/playsql/replace-schema.sql」として保存します(図6)。
ReplaceSchemaタスクは、DDL文実行前に接続したスキーマ上の既存の参照性整合制約と既存のテーブルを全て削除するため、指定するDDL文にDROP文は要りません。また、テーブルの名前が変更になったり、テーブルが削除されたりした場合の古いテーブルも綺麗に消えますので、テーブル再作成時の煩雑な手作業も発生しません。
また、初期テストデータが登録されているエクセルファイルを次のリンクからダウンロードすることができます。
ZIPファイルを解凍し「dbflute_exampledb/playsql/data」配下に配置します(図7)。
登録ユーザや更新日時などの共通列に固定値を簡単に登録したい場合は、default-value.txtにて定義を指定します。
ReplaceSchemaタスクは、このテキストファイルを参照してエクセルのテストデータとマージをします(リスト1)。
それでは、ReplaceSchemaタスクを実行してみましょう。「dbflute_exampledb」配下の「replace-schema.bat」をOSコマンド上で実行します(UNIX上では「replace-schema.sh」)。
すると、「dbflute_exampledb/playsql/replace-schema.sql」に記述されているDDL文が実行され、Excelのテストデータ登録されます。実行ログは「dbflute_exampledb/log/dbflute.log」に出力され、そのログから処理の成功・失敗が確認できます(図8)。
DBFluteにてスキーマ情報を取得
データベース上のテーブルの準備が整いましたので、スキーマ情報を取得するためにJDBCタスクを実行してみましょう。「dbflute_exampledb」配下の「jdbc.bat」をOSコマンド上で実行します(UNIX上では「jdbc.sh」)。
実行して成功すると、「dbflute_exampledb/schema」配下に「project-schema-exampledb.xml」が作成されます。データベースのスキーマ情報がこのXMLに出力されます。こちらの実行ログも「dbflute_exampledb/log/dbflute.log」にて確認できます。
DBFluteにてクラスを自動生成
スキーマ情報が取得できたので、DBFluteのクラスを自動生成するためにGenerateタスクを実行してみましょう。
「dbflute_exampledb」配下の「generate.bat」をOSコマンド上で実行します(UNIX上では「generate.sh」)。Eclipseにて該当プロジェクトを更新(F5)して生成されたクラスをEclipseに認識させます。「src/main/java」配下にクラスファイルが出力されいるのがわかります(図10)。こちらの実行ログも「dbflute_exampledb/log/dbflute.log」にて確認できます。
DBFluteのdiconファイルをインクルード
DBFluteを利用する場合は、DBFluteによって自動生成されたdbflute.diconを利用します。
Doltengで生成したsrc/main/resources配下にあるapp.diconは、dao.diconをインクルードしていますが、これをdbflute.diconに修正します(リスト2)。
実行時の接続データベースの設定
今回は、H2データベースを組込みとして利用します。先ほど、EMechaの画面にて、DB接続URLを「jdbc:h2:file:../src/main/resources/exampledb/exampledb」というように指定しました。同様に、jdbc.diconにて同じ場所を示す指定をします。
Doltengで作成した直後のjdbc.diconのDB接続情報は以下のようになっています(リスト3)。
ここの「URL」プロパティの値を以下のように変更します(リスト4)。
実行時のロギング設定
実行時のログの出力を調整します。「src/main/resources」の「log4j.properties」を開いて、以下の一行を追加します(リスト5)。
こちらは、必須事項ではありませんが、「Dolteng」で作成されたデフォルト設定のままだと、実行時に「コネクションの取得・閉じる」のログが大量に発生してしまい、非常にログの可読性が落ちてしまいます。
そこで、ピンポイントでそのログだけを抑制するようにします。但し、コネクション周りでのトラブルが発生したときは非常に有用なログになりますので、そのときは追加した一行を削除して下さい。
また、今回はアプリケーションのパッケージも「org.seasar」配下のため「たまたま」設定する必要が無いのですが、通常のアプリケーションのパッケージを指定する場合は、そのアプリケーションのパッケージを指定する必要があります。
以下はアプリケーションのパッケージが「jp.gihyo」だった場合の例です(リスト6)。
DBFluteの利用
それでは、ようやく準備が整いましたので、簡単なDBアクセスを試してみましょう。
Quick JUnitのインストール
単体テストの作成・実行を支援するプラグインがありますので、まずこちらをインストールします。これが無くてもテストを作成することはできますが、あると非常に便利です。
手順は更新サイトが変わるだけDoltengやEMechaをインストールしたときと同じ要領です。以下のような手順でインストールします。
- メニューにて「ヘルプ」-「ソフトウェア更新」-「検索とインストール」を選択
- フィーチャーの更新画面にて「インストールする新規フィーチャーを検索」-「次へ」を選択
- 更新アクセス先サイト画面にて「新規リモート・サイト」を選択
- ローカルサイトの編集ダイアログにて以下を入力してOKを選択
- Quick JUnitにチェックを付けて「完了」を選択
- 更新画面にて「Quick JUnit」を選択
- 次へを選択し、フィーチャー・ライセンスに同意しさらに次へ
- 終了を選択
テストクラスの作成
それでは、テストクラスを作成してみましょう。
- 「org.seasar.dbflute.example.gihyojp.dbflute.exbhv.MemberBhv」を開く
- カーソルをクラス宣言の括弧内に配置して「ctrl + 9」を押す
- 「テスティングペアがありません。作成しますか?」というダイアログが表示されるので、「はい」を選択
- テストケースの作成画面が表示されるので「ソースフォルダ」を以下のように修正
「dbflute-gihyojp-example/src/main/java」
→「dbflute-gihyojp-example/src/test/java」
- 「完了」を選択
すると、「src/main/test」配下に「org.seasar.dbflute.example.gihyojp.dbflute.exbhv.MemberBhvTest」が作成されます。
テストケースの作成
テストケースを作成して、DBアクセスしてみましょう。前回の記事で紹介した「ConditionBean」と「Behavior」を利用します(リスト7)。
カーソルををメソッドの宣言の括弧内に配置して「ctrl + 0」を押すと、テストが実行されます。
JUnitが緑を表示したら成功です。また、コンソールにSQL文と結果が表示されます(図11)。
簡単にログの説明をしておきます。
- MemberDao.selectList()
- 実際されたDaoクラスとそのメソッドです。
- MemberBhv.selectList() --> ...
- 呼び出されたBehaviorクラスとそのメソッドです。もし、さらにPageクラスを経由してBehaviorを呼び出した場合は、「MemberPage.doSearch():134 --> MemberBhv.selectList() --> ...」というようになります。
- SqlCommand Initialization Cost: [00m01s329ms]
- アプリケーションが起動して最初のアクセス時の初期化コストです。2回目以降の同じメソッドへのアクセス時には発生しません。よって、正確にDBアクセスのパフォーマンスを測る際は、2回目以降のDBアクセスを参考にします。
- select MEMBER.MEMBER_ID...
- 発行されたSQL文です。但し、これは人間が見やすいように編集されたSQLであり、実際にDBに発行されるSQLでは、バインド変数を利用しています。
- ===========/ [00m01s641ms - Selected list: 2 first={...
- SQLの実行結果のコストと結果件数と最初のレコードのトレースです。DBFluteでは、必ずこのようなデバッグログを出力し、開発者がデバッグしやすいようにしています。
次回
これにて実行環境が整いました。次回はConditionBeanの詳細な説明を実際に実行しながら進めていきたいと思います。