ハンズオンセクション 6

概要

さて、ハンズオンの続きです。

"デバッグログ設定と別名(和名)の利用" を学んでいきましょう。

事前準備

src/main/java 配下に org.docksidestage.handson.logic.HandsOn06Logic クラスを作成してください。この時点では空っぽで構いません。また、ERDを開いておくと良いでしょう。

【事務連絡】org.dbflute.handson から、org.docksidestage.handson に変わりました。 org.dbfluteで開始した人は、そのまま org.dbflute で続けてOKです。もし、移行するなら log4j.properties と basicInfoMap.dfprop の該当箇所を修正してください。

デバッグログ設定 (Lasta Di なら)

DIコンテナが Lasta Di であれば、logback になっています。

既に何度もデバッグログにはお世話になっているかと思います。 EclipseコンソールにはDBFluteの検索処理のログが出力されていたかと思います。 これは、既に src/main/resources 配下に logback.xml が(最初から)配置されているからです。ここでは簡単ではありますが、この設定ファイルを修正すると出力されるログが変更されることを学びましょう。

試しに、logback.xml の org.dbflute の logger タグをコメントアウトして、今まで作った任意のテストを実行し、コンソールのログを確認してみてください。変化があるはずです。 変化を確認したら、元に戻してもう一度テストを実行して確認しましょう。(元に戻さないとログが出なくなっちゃいますよぅ)

デバッグログ設定 (Seasarのままなら)

DIコンテナが Seasar のままであれば、logj4 になっています。

既に何度もデバッグログにはお世話になっているかと思います。 EclipseコンソールにはDBFluteの検索処理のログが出力されていたかと思います。 これは、既に src/test/resources 配下に log4j.properties (もしくは、src/main/resources に logback.xml) が(最初から)配置されているからです。ここでは簡単ではありますが、この設定ファイルを修正すると出力されるログが変更されることを学びましょう。

試しに、log4j.properties の log4j.logger.org.seasar を "#" でコメントアウトして、今まで作った任意のテストを実行し、コンソールのログを確認してみてください。変化があるはずです。 変化を確認したら、元に戻してもう一度テストを実行して確認しましょう。

また、log4j.appender.console.layout.ConversionPattern を "%d [%t]-%-5p - %m%n" に変更してみてください。変化を確認したら、元に戻してもう一度テストを実行して確認しましょう。

別名(和名)の利用

DBコメントの確認

replace-schema-10-basic.sql をご覧ください。 たくさんのDBコメントが定義されています。そして、DBコメントには、そのテーブルやカラムの別名(和名)と説明が "別名 : 説明" という形式で記載されています。(講師によるお話あり)

まず、SchemaHTML を開いて、DBコメントが "別名 : 説明" の形式であることを確認してください。(ただし、全てのコメントが必ずこの形式とは限りません)

ロジックの作成

それでは唐突ですが、JavaDoc上にDBコメントがあるかどうかを確認するために実装してみましょう。 以下のロジックを作成してテストしてみてください。実装しながら、それぞれのカラムに対応するメソッドの JavaDoc コメントを確認してみてください。特に別名は表示されていないはずです。

ロジックのメソッド
List<Member> selectSuffixMemberList(String suffix)
  • 指定された suffix で会員名称を後方一致検索
  • 会員名称の昇順で並べる
  • suffixが無効な値なら例外: IllegalArgumentException
  • 会員名称、生年月日、正式会員日時をログに出す (Slf4j or CommonsLogging)
  • そのログのログレベル、INFO/DEBUGどちらがいいか考えて実装してみましょう (この先ずっと同じ)
※こちらのメソッドは、他の人が呼び出すことを想定して public にしましょう。(この先ずっと同じ)
対応テストメソッド
test_selectSuffixMemberList_指定したsuffixで検索されること()
  • suffix は "vic" で
  • テストメソッド名通りのアサート
  • テストが成り立っていることも(できる範囲で)アサート (今後ずっとそう)
test_selectSuffixMemberList_suffixが無効な値なら例外が発生すること()
  • 無効な値とは、nullと空文字とトリムして空文字になる値

ちなみに、今回からエクササイズをより実践に近いもので行います。

  1. ロジッククラスにメソッドを定義して実装 (BehaviorはDIを利用)
  2. (Eclipseであれば) ctrl + 9 で対応するテストクラスを自動生成 (src/test/java に)
  3. テストメソッドを実装してロジックを検証

ロジッククラスでの Behavior の宣言は、以下のようにします。(講師によるDIのお話あり)

e.g. ロジッククラスでの Behavior の宣言 @Java
/**
 * @author jflute
 */
public class HandsOn06Logic {

    @Resource
    private MemberBhv memberBhv;

    ...
}

テストクラスでのロジックの利用方法は、以下のようにします。(講師によるUTFluteのお話あり)

e.g. テストクラスでロジッククラスを生成して利用 @Java
public void test_...() {
    // ## Arrange ##
    HandsOn06Logic logic = new HandsOn06Logic();
    inject(logic);
    
    // ## Act ##
    ... = logic.select...();
    ...
}

DBFluteプロパティの設定

それでは、ドキュメントに関するDBFluteプロパティ、DBFluteクライアントの dfprop/documentMap.dfprop を開いて、以下のプロパティを設定してみましょう。

aliasDelimiterInDbComment
DBコメント内の別名と説明の区切り(デリミタ)を表す文字
設定する値 => : (コロン)
isDbCommentOnAliasBasis
DBコメントの基本が別名か否か (デリミタがない場合にそれは別名なのかどうか)
設定する値 => true

再自動生成して確認

DBFluteプロパティの設定が終わったら、Docタスク、そして、Generateタスクを実行してみてください。 SchemaHTML、および、それぞれのカラムに対応するメソッドの JavaDoc コメントに変化があるはずです。

getであんまり検索したくない

ハンズオンでは、Logicの検索メソッドの名前は、select...() になっています。データを取得するからget?ではありません。 検索している、探している、ということを意識したいのです。

こういった考えでやっていますので、ぜひいちどお読みくださいませ。

ちょっと大文字にしてみましょうか

ハンズオンのMySQLでは、SQL上で大文字小文字を区別しないで済むような設定がされています。(講師による小話あり)

内部的には、テーブル名を全て小文字で管理することによって実現されています。 よって、DBFluteが取得するメタデータなどが小文字になっています(SchemaHTMLやCBで実行されたSQLなど)。 これを、大文字にするという地味な機能が用意されています。以下のプロパティ(littleAdjustmentMap.dfprop)を設定して再自動生成して確認してみてください。

e.g. DBFlute管理上ではテーブル名を大文字に @littleAdjustmentMap.dfprop
; isTableDispNameUpperCase = true
e.g. DBFluteで発行するSQLのテーブル名やカラム名を大文字に @littleAdjustmentMap.dfprop
; isTableSqlNameUpperCase = true
; isColumnSqlNameUpperCase = true

そもそもテーブル名やカラム名を大文字とするか小文字とするかは、文化や組織によって異なるものです。 どちらが良いという話ではなく、ERDなどのドキュメントと合わせるための地味機能と捉えてください。 (とはいえ、小文字にするプロパティは用意されてないのですが...)

ハンズオンでは、これらプロパティを true に設定して、再自動生成してそれぞれ大文字になっていることを確認してみましょう。

空文字をDBに入れたくない

DB上の空文字は、地味にトラブルを引き起こす可能性があります。 (講師による小話あり)

次のセクションから、登録や更新処理を行います。 この時点で、DBに空文字が入らないように施策を打っておきます。 以下のプロパティ(littleAdjustmentMap.dfprop)を再自動生成しておきましょう。

e.g. Entityにセットされた空文字をnullに変換 @littleAdjustmentMap.dfprop
; isEntityConvertEmptyStringToNull = true

次のセクション

さて、次のセクションへ