2013年9月4日水曜日

列挙型ドメインとマスタ化の判断基準

画面上での選択肢(コンボボックス等)を実装する手段としては、列挙型ドメインの定義とトランザクションでマスタテーブルを作る方法の2種類ありますが、皆さんはどういうケースで列挙型ドメインにし、どういうケースでマスタ化を選択しますか?





プロジェクトの方針にもよると思いますが、私は以下の様に考えます。

1.列挙型ドメインを選択する場合

選択肢自体が固定的、つまりシステムの運用時には選択肢の変更(追加や削除含む)が無い場合は列挙型を採用します。

列挙型ドメインの定義

Enum Valuesプロパティで列挙子を定義

項目属性のタイプとして列挙型ドメインを指定するだけで
Control TypeがCombo Boxになる


特に区分やステータスなど選択肢自体に意味があり、ソース上で選択肢となる値を直接コーディング(ハードコーディング)する場合です。

For eachコマンドの条件に列挙子を使用しているところ


列挙型ドメインの変更にはビルドが必要ですが、合わせてプログラムの修正が必要な場合も多いためあまり問題になりません。



2.マスタ化を選択する場合

選択肢自体が可変的、つまりシスタムの運用時に変更がある場合はマスタ化して利用者が直接メンテナンスできる様にする必要があります。
GeneXusでは新たにマスタ用トランザクションを作成し、コード用項目属性、名称用項目属性を定義します。

あらたにCustomerStatusトランザクションを定義

ビルド後にレコードを登録しておく必要がある



マスタを参照する側のトランザクションでは、外部キー項目属性をDynamic Combo(ダイナミックコンボ)に設定します。これにより、固定値の選択肢ではなく、都度マスタのレコードをセレクトして表示するコンボボックスが利用できます。

外部キー項目属性のControl TypeをDynamic Comboに変更
ItemDescriptionsプロパティに名称項目を指定


Dynamic Comboを設定すると、自動生成画面ではコード・名称という2つの項目ではなく
コンボボックス1つの項目として生成される
外部キー項目属性がコンボボックスに、名称項目属性が非表示に


この場合の注意点としてはマスタのコード値はソースコード上ではハードコードしてはいけません。可変的なメリットがなくなりますし、勝手にコード値を追加してしまうと誤作動の元になります。

例外的なケースとしては、選択肢の名称をプログラムの変更なく運用者がメンテナンスしたい場合です。この時はマスタ化しつつ、コード値をハードコーディングする事を許可しますが、マスタメンテナンス機能としては、新規追加や削除機能を禁止しておく必要があります。(GeneXusにおいては主キー項目は値の変更が不可なので、変更を許可しても上記要件は満たせます)




3.Tips マスタ初期データ投入プロシージャ

上記2のケース(選択肢をマスタ化)では、ビルド後マスタのデータを登録する必要があります。しかし、手動での登録は煩わしいですし、間違った値を登録すると誤動作の原因にもなります。

一般的にはINSERTのSQL文を作成しますが、これだとDBMSが固定化されてしまいGeneXusのメリットが享受されづらいです。

私のお勧めはデータ投入用のプロシージャを作成する事です。これによりDBMSに依存する事なく、データ投入ができますし、ナレッジベースに同梱される事にもなるので、開発者が増えたり、新しい環境でビルドする時にもプロシージャの実行だけで事足りるので非常に便利です。


大量のデータ投入には向きませんが、本格的な開発では色々なマスタのデータ準備が必要で、ビルドするだけではシステムをテストする事もままなりません。マスタデータ投入用プロシージャを是非活用してみて下さい。




0 件のコメント:

コメントを投稿