}一つの区分値に複数の区分値要素を定義します。nameはENUMの名前にも利用されるので、クラス名で利用できない文字列を含めることはできません。(先頭が数字とか)listの中の一つ一つのmapが一つ一つの区分値要素に対応します。codeやnameなどの意味と役割は「A」だけでなく他のやり方でも同様です。map:{...}どのテーブルのどのカラムにどの区分値を関連付けるかを定義します。$$ALL$$は「全てのテーブルの該当するカラムに関連」となります。中間一致ヒントは主に$$ALL$$と合わせると良いでしょう。MEMBER_STATUS_CODEを表現するカラムがどのテーブルでも「MEMBER_STATUS_CODE」と完全一致する、もしくは、で終わるとかであれば、$$ALL$$に関連付ければ設定は楽になります。「A」は、非常にプリミティブなインターフェースです。その他の方法を利用するにしても、この方法と併用することがありますし、また、区分値を定義するとはどういうことなのかを理解するのに非常にわかりやすい仕様なので、この方法は必ず覚えておくと良いでしょう。「区分値定義の一元管理」がこの方法で一番課題になる部分です。区分値定義を他のところで管理する場合は、設定ファイルを自動生成でもしない限りは定義が冗長化します。その場合は、ちょっとしたScriptを独自に作ってこの区分値定義を自動生成するようにするのがお奨めです。DBFluteプロパティの区分値定義で管理するの問題ないなら、それはそれで良いでしょう。区分値は必ずディベロッパーや仕様策定車の見やすい形で提供することが大切です。三つのポイントの一つ「ディベロッパーへの横展開」です。このDBFluteプロパティではそれを満たせませんが、Docタスクで生成されるSchemaHTMLで定義された区分値を一覧として参照することができます。その一覧へ、それぞれのカラムのからリンクで辿れます。dbflute-basic-exampleのSchemaHTMLをご覧下さい。MEMBERのMEMBER_STATUS_CODEのMemberStatusへのリンクから区分値の一覧へ飛んで見て下さい。実際の業務ではかなり壮観なドキュメントとなります。区分値の「ディベロッパーへの横展開」はこれでかなりいい感じです。これは「A」以外の方法でも共通です。DBFluteのClassification機能を利用する限りはこの恩恵を得ることができます。テーブル区分値#テーブル区分値とは、テーブルのデータとして管理されている区分値です。ExampleDBで言うと、MEMBER_STATUSがまさにそうです。FK制約でのチェックも入り、SQLでの結合で名称など取得することができるため、そのメリットは大きいです。jflute自身もDB設計をやるときはこのようにテーブル区分値を利用します。(但し、全ての区分値を一つのテーブルにまとめるやり方は絶対にしない)この場合、区分値はマスタデータとして管理されます。ReplaceSchemaで利用するエクセルデータとして管理したり、その他別の方法でとにもかくにもDBに登録することになります。その状況で「A」の方法でそのままベタにDBFluteプロパティに定義をすると、定義が冗長することになります。実はDBFlute自身がそれに近いやり方を既に提供しています。GenerateタスクやDocタスク実行時に、区分値が登録されたテーブルに対して、実際にSQL文を発行して定義を取得する機能があります。}区分値がどのテーブルのどのカラムに定義されているかを設定します。tableが指定されていることがテーブル区分値であることの目印となります。このように設定するとGenerateタスクやDocタスク実行時に、これらの情報を元にSelect文を発行して区分値定義を取得します。これにより、「区分値定義の一元管理」は解決です。エクセルに区分値を追加したらReplaceSchemaを実行して、GenerateタスクやDocタスクを実行すれば、その追加された区分値はすぐに自動生成されたクラスやSchemaHTMLに反映されます。「ディベロッパーへの横展開」は「A」と同じくSchemaHTMLです。テーブル区分値をExcelで管理しているくらいなら、それをReplaceSchemaで実行して(できるようにして)、この「B」の方法を利用すればDBFluteのClassification機能のメリットを簡単に享受できます。区分値の配置(classificationDeploymentMap.dfprop)の設定は要りません。DBFluteがどのカラムが区分値対象なのかを区分値の定義から判断して、かつ、リレーションを辿って自動登録します。実は、これが「DBFLUTE-495」での修正で、DBFlute-0.9.5.1からの仕様となります。それまでは区分値定義はDBから取得するものの、それを「A」と同じようにカラムに関連付けてあげる必要がありました。いうこともあり、DBから取得する機能はずっと前のバージョンからあったにも関わらず露出が少なかった要因の一つです。この機能を利用される場合は、DBFlute-0.9.5.1以降を利用する方が良いでしょう(C#版だとDBFlute.NET-0.8.9.1以降)。日本のシステムだと、コードと日本語名だけで管理するテーブルが多いかと思われます。実際にアプリケーションとしてはそれだけしか必要としないからです。すると、メソッド名などで利用する区分値の名前(name)をコードと日本語名のどちらかにするしかありません。上記のMEMBER_STATUSの例を見ると日本語名をnameに指定して、aliasは省略してnameと同じになるようにしています。すると、生成される区分値のメソッド名の一部は日本語になってしまいます。それで問題ないというのであれば、特に気にすることはありません。日本語名のメソッドはそれはそれでとてもわかりやすいです。気になる方は、コードをnameにするか、別途英名が格納されるカラムを追加して、それをnameに指定した方がよいでしょう。フラグのようなテーブル区分値にはなかなかならないものは、やはり「A」のやり方を使って定義します。「A」と「B」は併用するような形となります。この方法を利用したExampleはdbflute-guice-exampleです。ERDコメント#「ディベロッパーへの横展開」を徹底して追求した方法です。ERDのコメントに書くのは非常に効果があります。ExampleDBのERDをご覧下さい。ドキュメントがたくさんあるのもよくありません。ディベロッパーは他にもたくさんドキュメントを見る必要があり、あまり多いと見なくなってしまう可能性があります。ERDの中に区分値が表現されていれば、あっちみたりこっちみたりをする必要がなくなります。際の中心的なドキュメントです。ERDみながら会話をして仕様のやり取りをします。そのとき区分値の定義が一緒であれば、会話が弾みます。印刷したりとかしないものです。「確かこうそういう区分値があったから、これこれこうだよな」って曖昧な確認で会話を終わらせてしまいがちです。エクセル(だけ)で管理されているのを見掛けますが、あまり参照されないドキュメントになるのをよくみかけます。気軽に開けて参照しやすいドキュメントが良いです。開きっぱなしにしづらい(したくない)ものです。開きやすいこと、開きっぱなしにしやすいこと、これが大事です。ERDは大抵のツールでHTML出力できます。SchemaHTMLも同様ですが、ブラウザは大抵の人が起動しっぱなしで扱いやすく、今の時代のブラウザならWindowsのタスクバーを埋め尽くすこともないでしょう。(エクセルだとすごいあっという間に埋まりますよね...)と、ERDのコメントに書くことが有効であるということを語らせて頂きましたが、そのコメント上の定義をDBFluteの区分値定義に関連付けてあげなければなりません。そこで、コメント欄に区分値を書くときに、とある規則で書くようにします。...「区分値タイトル」は中身は任意で特にDBFluteでは利用しません。"[Xxx]"の形式で書いてあれば何でもよく、わかりやすい業務的なタイトルをつけるのがドキュメント的に好ましいです。「関連付けるカラム名」はclassificationDeploymentMap.dfpropの「$$ALL$$」に関連付けるカラムを指定する項目です。"[Xxx]"の後の半角コロン「:」で区切ったその後の文字列が全てカラム名として扱われます。前方一致や後方一致を表現するときは「*」を利用します。「*_FLG」で「_FLG」で終わるカラムに関連付けることになります。classificationDeploymentMap.dfpropを利用して個別定義も可能です。別名とコメントは任意で、省略時はカンマも省略して構いません。「コメント文字列を含んだなにかしらのテキスト」を出力して下さい。区分値定義の文字列が改行が保たれたまま含まれていれば、XMLでもHTMLでも形式はなんでも構いません。Architect)であればXMLファイルをエクスポートすればOKです。(記事上の都合によりわざと空白あけて記載しています)Encodingはデフォルトで「UTF-8」。XML定義のように一行目に「encoding="SHIFT_JIS"」というように定義されている場合はSHIFT_JISとなります。(EAで出力したXMLであればこれが活用されます)それを、classificationResource.dfpropという名前でdfprop配下に配置します。DBFluteはこのファイルの中の文字列から決められたフォーマットの区分値定義を読み込んで自動登録します。テーブル区分値の場合は、そのテーブルのデータとERDのコメント欄の定義が冗長化してしまうところがトレードオフです。「区分値定義の一元管理」に問題があります。こちらは現在改善を模索中です。テーブルとカラムの対応を定義するようにして(できるだけ簡単に)、ReplaceSchemaでそれを読み取って、自動で登録するような形にできないかと。この方法を利用したExampleはdbflute-mysql-exampleです。ERDコメント>区分値定義の一元管理:テーブル区分値だとOUT!ディベロッパーへの横展開:Best!テーブル区分値なら「B」を利用して、フラグなどテーブルで管理されないちょっとした区分値に対してのみ「A」を利用する、が一番の基本になります。「C」はDBAの気合いが要りますが、乗り越えればかなり強力でしょう。補足1#区分値を利用したいのは、DBFluteが自動生成したEntityやConditionBeanだけではありません。アプリケーションで作成したDTOなどで利用したい場合もあります。その場合は、allcommonパッケージ配下に生成される「CDef」というクラスを利用します。「CDef」は「ClassificationDefinition」の略です。CDefはインターフェースで、そのインナークラスとして全ての区分値ENUMが定義されていて、「CDef.MemberStatus」というように利用できます。CDef.MemberStatus.codeOf(code);全ての区分値ENUMはCDefインターフェースをImplementsしています。code()やname()やalias()を透過的に扱うことも可能です。実はこれが「DBFLUTE-505」となります。「一つ一つのENUMを一つのJavaファイルで作るか、CDefにまとめるか」です。一つ一つのENUMを一つのJavaファイルになっている方が一般的かなと思っていながらも、実現する上で内部的な管理が煩雑になりやすいので、CDefにまとめる方法を採用しました。DBFlute方式だと、ディベロッパーはこのCDefはほとんど意識する必要ないというのも理由で。いざCDefを直に使う機会があって使ってみると、非常に実装がしやすいことがわかりました。いうのは「CDef」と書いて補完をすればENUMの一覧が補完されてJavaDocも見れてわかりやすいからです。これがそれぞれ独立したENUMだとまずどんなENUMがあるのか知ってないとファーストタッチが進みません。テーブル区分値の場合は、Entityのクラス名と区分値のENUM名が似てることが多く(というか全く同じとか)、すると、補完する上でとても面倒になりやすいです。結果的に「CDef」で良かったと思っています(実現も管理も楽だし)。補足2#Classification機能を使っても、Entityのプロパティの型は変わりません。ネイティブな型でのSetterなどは残っています。WEBだとコード値そのままで扱うことも多いため「2」の外部ツールは例えばBeanUtilsなどリフレクションでDTOと詰め替えるようなユーティリティです。YmirのConverterも同様です。ネイティブな型でのSetterが無いとそういったツールと非常に相性が悪くなってしまいます。アプリケーションで独自にそういった仕組みを実装するときも、その部分がトラブルを生みやすくなります。「3」は、例えばリストボックスで選択された値をそのまま条件にして検索するというような場合、文字列として飛んで来たコード値をそのままConditionBeanに格納します。ネイティブな型でのSetterがなければ、あまりENUMとして扱うことに意味がないにも関わらず、Setする直前でCDef.MemberStatus.codeOf(code)とやる必要があります。結局codeOfを使えば不正な値は簡単に入れられてしまうので、それよりはバランスのとれた区分値支援に徹するようにしました。仕組みがデフォルトで設けられていたらなぁと思います。期待できるものではありません。最後に#やはり、DBFluteプロパティ(dfprop)の色付けや補完をするエディタが欲しいですよね。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。