DBアクセスを定番化しよう DBFlute入門

第2回DBFluteではじめてのDBアクセス

はじめに

前回は、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プラグインです。

以下のような手順でインストールします。

  1. メニューにて「ヘルプ⁠⁠-⁠ソフトウェア更新⁠⁠-⁠検索とインストール」を選択
  2. フィーチャーの更新画面にて「インストールする新規フィーチャーを検索⁠⁠-⁠次へ」を選択
  3. 更新アクセス先サイト画面にて「新規リモート・サイト」を選択
  4. ローカルサイトの編集ダイアログにて以下を入力してOKを選択図1
  5. Seasar-3.3にチェックを付けて「完了」を選択
  6. 更新画面にて「Seasar-3.3⁠⁠-⁠Dolteng」を選択[2]
  7. 更新画面にて「Seasar-3.3⁠⁠-⁠EMecha」を選択
  8. 次へを選択し、フィーチャー・ライセンスに同意しさらに次へ
  9. 終了を選択
図1 新規リモート・サイト画面
図1 新規リモート・サイト画面

プロジェクト作成{Dolteng利用}

プラグインの準備ができたので、いよいよEclipseのプロジェクトを作りましょう図2⁠。

  1. メニューにて「新規⁠⁠-⁠プロジェクト」を選択
  2. ウィザード選択画面にて「Chura Project」を選択
  3. プロジェクト名とルートパッケージを入力
    • ロジェクト名 : dbflute-gihyojp-example
    • ルートパッケージ : org.seasar.dbflute.example.gihyojp
  4. プロジェクトタイプで「Super Agile(Teeda + S2Dao⁠⁠」を選択
  5. 完了(プロジェクトが作成される)
図2 プロジェクト作成画面
図2 プロジェクト作成画面

すると、⁠dbflute-gihyojp-example」というEclipseのプロジェクトが作成されます図3⁠。

図3 作成直後のEclipseプロジェクト
図3 作成直後のEclipseプロジェクト

環境構築手順{EMecha利用}

Eclipseのプロジェクトの作成できたので、そのプロジェクトにDBFluteクライアント環境を作成します。EMechaを利用すると、クライアント環境の作成と同時にDBFluteのモジュール本体の設置も行うことができます。

EMechaのDBFluteクライアント作成画面を利用します図4⁠。

  1. Doltengで作成したプロジェクト「dbflute-gihyojp-example」を選択(パッケージエクスプローラ上にて)
  2. メニューにて「新規⁠⁠-⁠その他」を選択
  3. ウィザード選択画面にて「DBFlute Client Directory」を選択
  4. 画面にて以下の入力項目を入力
    項目入力値
    Container Namedbflute-gihyojp-example ※自動設定
    Projectexampledb
    Databaseh2 ※リストボックスにて選択
    Target Languagejava
    Target Containerseasar
    Package Baseorg.seasar.dbflute.example.gihyojp.dbflute
    Driverorg.h2.Driver ※「Database」の選択次第で自動設定
    Urljdbc:h2:file:../src/main/resources/exampledb/exampledb
    Schema(空)
    Usersa
    Password(空)
  5. 画面にて「Latest Version ⁠From WebSite⁠⁠」ボタンを選択
  6. 画面にて「Download DBFlute」ボタンを選択 ※注:ダウンロードに多少時間が掛かります。
  7. 終了を選択
  8. プロジェクト「dbflute-gihyojp-example」を選択して最新化(F5)
図4 EMechaのDBFluteクライアント作成画面
図4 EMechaのDBFluteクライアント作成画面

すると、dbflute-gihyojp-example配下に「dbflute_exampledb」「mydbflute」が作成されます図5⁠。

図5 EMechaで作成したDBFlute環境
図5 EMechaで作成したDBFlute環境

それぞれの入力項目の概要説明は以下の通りです。

項目概要
ProjectDBFluteクライアントの任意のプロジェクト名。通常はDBの名称やアプリの名称などを入れる。
Database利用するデータベースの種別。リストボックスにて選択。
Target Language自動生成するクラスの言語。リストボックスにて選択。
Target Container利用するDIコンテナ。リストボックスにて選択
Package Base自動生成するクラスのパッケージを指定。通常はルートパッケージ + 'dbflute'。
Driver DB接続で利用するドライバ名。項目「Database」が選択されると自動的にドライバ名が設定される。
UrlDB接続URL。
SchemaDB接続スキーマ。データベースによっては指定無しでもOK。
UserDB接続ユーザ。
PasswordDB接続パスワード。
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文は要りません。また、テーブルの名前が変更になったり、テーブルが削除されたりした場合の古いテーブルも綺麗に消えますので、テーブル再作成時の煩雑な手作業も発生しません。

図6 ReplaceSchemaタスクで利用するDDL文の配置
図6 ReplaceSchemaタスクで利用するDDL文の配置

また、初期テストデータが登録されているエクセルファイルを次のリンクからダウンロードすることができます。

ZIPファイルを解凍し「dbflute_exampledb/playsql/data」配下に配置します図7⁠。

図7 ReplaceSchemaタスクで利用するテストデータの配置
図7 ReplaceSchemaタスクで利用するテストデータの配置

登録ユーザや更新日時などの共通列に固定値を簡単に登録したい場合は、default-value.txtにて定義を指定します。

ReplaceSchemaタスクは、このテキストファイルを参照してエクセルのテストデータとマージをしますリスト1⁠。

リスト1:ReplaceSchemaタスクで利用する共通列の固定値定義
map:{
; REGISTER_DATETIME = sysdate
; REGISTER_USER     = replace-schema
; REGISTER_PROCESS  = replace-schema
; UPDATE_DATETIME   = sysdate
; UPDATE_USER       = replace-schema
; UPDATE_PROCESS    = replace-schema
; VERSION_NO        = 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⁠。

図8 ReplaceSchemaタスクの実行ログファイル
図8 ReplaceSchemaタスクの実行ログファイル

DBFluteにてスキーマ情報を取得

データベース上のテーブルの準備が整いましたので、スキーマ情報を取得するためにJDBCタスクを実行してみましょう。⁠dbflute_exampledb」配下の「jdbc.bat」をOSコマンド上で実行します(UNIX上では「jdbc.sh⁠⁠。

実行して成功すると、⁠dbflute_exampledb/schema」配下に「project-schema-exampledb.xml」が作成されます。データベースのスキーマ情報がこのXMLに出力されます。こちらの実行ログも「dbflute_exampledb/log/dbflute.log」にて確認できます。

図9 JDBCタスクで生成したスキーマXMLファイル
図9 JDBCタスクで生成したスキーマXMLファイル

DBFluteにてクラスを自動生成

スキーマ情報が取得できたので、DBFluteのクラスを自動生成するためにGenerateタスクを実行してみましょう。

「dbflute_exampledb」配下の「generate.bat」をOSコマンド上で実行します(UNIX上では「generate.sh⁠⁠。Eclipseにて該当プロジェクトを更新(F5)して生成されたクラスをEclipseに認識させます。⁠src/main/java」配下にクラスファイルが出力されいるのがわかります図10⁠。こちらの実行ログも「dbflute_exampledb/log/dbflute.log」にて確認できます。

図10 GenerateタスクでされたDBFluteのパッケージ構造
図10 GenerateタスクでされたDBFluteのパッケージ構造

DBFluteのdiconファイルをインクルード

DBFluteを利用する場合は、DBFluteによって自動生成されたdbflute.diconを利用します。

Doltengで生成したsrc/main/resources配下にあるapp.diconは、dao.diconをインクルードしていますが、これをdbflute.diconに修正しますリスト2⁠。

リスト2:app.diconにてdbflute.diconをインクルード
<include path="dao.dicon"/>
      
<include path="dbflute.dicon"/>

実行時の接続データベースの設定

今回は、H2データベースを組込みとして利用します。先ほど、EMechaの画面にて、DB接続URLを「jdbc:h2:file:../src/main/resources/exampledb/exampledb」というように指定しました。同様に、jdbc.diconにて同じ場所を示す指定をします。

Doltengで作成した直後のjdbc.diconのDB接続情報は以下のようになっていますリスト3⁠。

リスト3:Doltengで作成直後のjdbc.diconのDB接続情報
<!-- for H2 -->
<component name="xaDataSource"
  class="org.seasar.extension.dbcp.impl.XADataSourceImpl">
  <property name="driverClassName">
    "org.h2.Driver"
  </property>
  <property name="URL">
    "jdbc:h2:tcp://localhost:9092/demo"
  </property>
  <property name="user">"sa"</property>
  <property name="password">""</property>
  <destroyMethod>
    @org.seasar.framework.util.DriverManagerUtil@deregisterAllDrivers()
  </destroyMethod>
</component>

ここの「URL」プロパティの値を以下のように変更しますリスト4⁠。

リスト4:今回のサンプルで利用するH2への接続するためのURL
<property name="URL">
  "jdbc:h2:file:"
  + @org.seasar.framework.util.ResourceUtil@getBuildDir(@org.seasar.dbflute.example.gihyojp.dbflute.allcommon.Entity@class).getCanonicalPath()
  + "/exampledb/exampledb"
</property>

実行時のロギング設定

実行時のログの出力を調整します。⁠src/main/resources」「log4j.properties」を開いて、以下の一行を追加しますリスト5⁠。

リスト5:log4j.propertiesのログ対象調整
log4j.category.org.seasar=DEBUG
log4j.category.org.seasar.extension.dbcp=INFO

こちらは、必須事項ではありませんが、⁠Dolteng」で作成されたデフォルト設定のままだと、実行時に「コネクションの取得・閉じる」のログが大量に発生してしまい、非常にログの可読性が落ちてしまいます。

そこで、ピンポイントでそのログだけを抑制するようにします。但し、コネクション周りでのトラブルが発生したときは非常に有用なログになりますので、そのときは追加した一行を削除して下さい。

また、今回はアプリケーションのパッケージも「org.seasar」配下のため「たまたま」設定する必要が無いのですが、通常のアプリケーションのパッケージを指定する場合は、そのアプリケーションのパッケージを指定する必要があります。

以下はアプリケーションのパッケージが「jp.gihyo」だった場合の例ですリスト6⁠。

リスト6:log4j.propertiesのアプリログ出力設定
log4j.category.org.seasar=DEBUG
log4j.category.org.seasar.extension.dbcp=INFO
log4j.category.jp.gihyo=DEBUG

DBFluteの利用

それでは、ようやく準備が整いましたので、簡単なDBアクセスを試してみましょう。

Quick JUnitのインストール

単体テストの作成・実行を支援するプラグインがありますので、まずこちらをインストールします。これが無くてもテストを作成することはできますが、あると非常に便利です。

手順は更新サイトが変わるだけDoltengやEMechaをインストールしたときと同じ要領です。以下のような手順でインストールします。

  1. メニューにて「ヘルプ⁠⁠-⁠ソフトウェア更新⁠⁠-⁠検索とインストール」を選択
  2. フィーチャーの更新画面にて「インストールする新規フィーチャーを検索⁠⁠-⁠次へ」を選択
  3. 更新アクセス先サイト画面にて「新規リモート・サイト」を選択
  4. ローカルサイトの編集ダイアログにて以下を入力してOKを選択
  5. Quick JUnitにチェックを付けて「完了」を選択
  6. 更新画面にて「Quick JUnit」を選択
  7. 次へを選択し、フィーチャー・ライセンスに同意しさらに次へ
  8. 終了を選択

テストクラスの作成

それでは、テストクラスを作成してみましょう。

  1. 「org.seasar.dbflute.example.gihyojp.dbflute.exbhv.MemberBhv」を開く
  2. カーソルをクラス宣言の括弧内に配置して「ctrl + 9」を押す
  3. 「テスティングペアがありません。作成しますか?」というダイアログが表示されるので、⁠はい」を選択
  4. テストケースの作成画面が表示されるので「ソースフォルダ」を以下のように修正
     ⁠dbflute-gihyojp-example/src/main/java」
    ⁠dbflute-gihyojp-example/src/test/java」
  5. 「完了」を選択

すると、⁠src/main/test」配下に「org.seasar.dbflute.example.gihyojp.dbflute.exbhv.MemberBhvTest」が作成されます。

テストケースの作成

テストケースを作成して、DBアクセスしてみましょう。前回の記事で紹介した「ConditionBean」「Behavior」を利用しますリスト7⁠。

リスト7:まずはじめのDBアクセス
public class MemberBhvTest extends S2TestCase {// TestCase → S2TestCase

  private static final Log log = LogFactory.getLog(MemberBhvTest.class);

  private MemberBhv memberBhv;
    
  @Override
  public void setUp() throws Exception {
    super.setUp();
    include("dbflute.dicon");
  }
  
  public void test_FirstImpact_Tx() throws Exception {
    // ## Arrange ##
    final MemberCB cb = new MemberCB();
    cb.query().setMemberName_PrefixSearch("ス");
    
    // ## Act ##
    final ListResultBean<Member> memberList = memberBhv.selectList(cb);
    
    // ## Assert ##
    for (Member member : memberList) {
      final Integer memberId = member.getMemberId();
      final String memberName = member.getMemberName();
      log.debug("  " + memberId + " - " + memberName);
      assertTrue(memberName.startsWith("ス"));
    }
  }
}

カーソルををメソッドの宣言の括弧内に配置して「ctrl + 0」を押すと、テストが実行されます。

JUnitが緑を表示したら成功です。また、コンソールにSQL文と結果が表示されます図11⁠。

図11 初めてのDBアクセスの実行ログ
図11 初めてのDBアクセスの実行ログ

簡単にログの説明をしておきます。

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の詳細な説明を実際に実行しながら進めていきたいと思います。

おすすめ記事

記事・ニュース一覧