WAGBY11 MANUAL / 29
英語識別名と生成Java名の対応
Java開発者向けに、英語識別名と生成Java名の対応、生成ソースの位置とパッケージ構成を説明します。
最終更新日:
Java開発者向け:生成されたJavaコードを参照したり、Javaカスタマイズを行ったりする際の名前の対応を説明します。
1. このページで伝える機能
AppSchemaの英語識別名と、生成されるJavaクラス名・アクセサ名は、常に同じ表記になるとは限りません。Javaコードを書くときは、英語識別名から名前を推測するだけでなく、生成ソースで実際の宣言を確認します。表示名・英語識別名・DB物理名の基本は、モデルと項目の名前を決めるを参照してください。
2. Wagby11で実現できること
2.1 英語識別名からJavaクラス名を生成する
モデルのname_enからクラス名を生成するときは、アンダースコアで区切った各部分を小文字にし、先頭だけを大文字にして連結します。英語識別名の途中の大文字が、そのままJavaクラス名に残るとは限りません。
| モデルの英語識別名 | 生成Javaクラス名 |
|---|---|
ModelA | Modela |
PRODUCTCATEGORY | Productcategory |
PRODUCT_CATEGORY | ProductCategory |
ModelAのような途中に大文字を含む英語識別名を使用できます。生成クラス名の表記に合わせるために、AppSchemaの英語識別名までModelaへ変更する必要はありません。
2.2 生成クラス名の衝突を避ける
生成クラス名は、AppSchema全体で大文字・小文字を区別せず一意にする必要があります。次の組み合わせは、別モデルとして併存させられません。
| 英語識別名の組み合わせ | 衝突する理由 |
|---|---|
ModelAとModela | どちらもModelaになります。 |
PRODUCT_CATEGORYとPRODUCT__CATEGORY | どちらもProductCategoryになります。 |
PRODUCTCATEGORYとPRODUCT_CATEGORY | ProductcategoryとProductCategoryは、大文字・小文字を区別しない比較で一致します。 |
大文字・小文字を区別しないファイルシステムで生成ファイルが衝突する組み合わせは、使用するOSにかかわらずコード生成前に検証エラーとなります。ドメインやDB物理名のrdbnameを変更しても解消しません。エラーに表示された英語識別名とクラス名を確認し、業務上の違いが分かる別の英語識別名を選びます。
既存モデルの英語識別名を変更する場合は、参照している定義やカスタマイズへの影響も確認します。同じモデルの名前変更では、既存のmigration_idを保持します。詳しくは名前を変更しても、同じモデル・項目を追跡するを参照してください。
2.3 Entity・DTO・JSONの項目名を確認する
項目の英語識別名には、jNoのように小文字1字の後に大文字が続く名前も使用できます。この場合、EntityとOpenAPI生成DTOでは、値を取得するアクセサの表記が異なります。
| 対象 | 項目の英語識別名がjNoの場合 |
|---|---|
| Entityの取得アクセサ | getJNo() |
| OpenAPI生成DTOの取得アクセサ | getjNo() |
| JSONのプロパティ名 | jNo |
生成MapperがEntityとDTOの対応付けを行います。JavaカスタマイズでDTOを直接扱うときは、Entityと同じアクセサ名と決めつけず、対象の生成ソースを確認します。アクセサ名の違いを解消するために、項目の英語識別名の先頭を書き換える必要はありません。
3. 生成ソースの位置とパッケージ構成
3.1 生成ソースの位置
generateコマンドは、AppSchemaからEntity、Repository、Service、Controller、MapperなどのJavaソースを生成します。出力先は--output、ルートパッケージは--packageで指定します。
標準のrestapi/generate.shは、restapiを基準として--output src/main/java、--package jp.jasminesoft.wagby.appを指定します。このため、生成ソースはrestapi/src/main/javaの下に置かれます。Javaのパッケージ名のドットは、フォルダの区切りに対応します。
例えば、英語識別名がCharacterSetSampleのモデルでは、Entityのクラス名はCharactersetsampleとなり、標準構成での配置は次のようになります。
restapi/src/main/java/
jp/jasminesoft/wagby/app/
charactersetsample/
entity/Charactersetsample.java
repository/CharactersetsampleRepository.java
service/CharactersetsampleCommandService.java
controller/CharactersetsampleController.java
mapper/CharactersetsampleDetailMapper.java
このEntityのパッケージ宣言はjp.jasminesoft.wagby.app.charactersetsample.entityです。出力先やルートパッケージを変更して実行する場合は、その指定に合わせて探します。
3.2 モデル別・役割別のパッケージ構成
ルートパッケージの下にはモデルごとのパッケージがあり、その中を役割別に分けます。上の例ではcharactersetsampleがモデルのパッケージです。主な役割は次のとおりです。定義した機能によって生成されるクラスやパッケージは異なります。
| モデル配下のパッケージ | 主な役割 |
|---|---|
entity | DBへ保存するデータを表すEntity。項目のアクセサを確認します。 |
repository | EntityをDBから取得・保存するためのRepository。 |
service | 登録・更新・削除、検索、フォーム取得などの処理。 |
controller | REST APIの要求を受け付け、Serviceへ処理を渡すController。 |
mapper | Entityとリクエスト・レスポンスDTOの間の項目の対応付け。 |
validator | 入力チェックと業務上の検証。 |
inputfilter | 入力値の正規化。 |
calculator | 項目の計算。 |
initializer | フォームや検索条件の初期値の設定。 |
search | 検索条件の正規化、条件の組み立て、並び順の解決。 |
visibility | 項目の表示・編集可否などの解決。 |
customization | AppSchemaに定義したルールの情報。手書きJavaの保存先とは別です。 |
例えば、APIへ返す項目の対応を確認する場合はmapper、DBへ保存する項目を確認する場合はentityを起点にします。各ファイルのpackage宣言とimportをたどると、関連するクラスを確認できます。
3.3 DTOのソースとカスタマイズの配置
OpenAPIから生成するDTOは、標準構成ではjp.jasminesoft.wagby.app.generated.modelパッケージに置かれます。ソースはrestapi/target/generated-sources/openapi/src/main/javaの下にあり、モデル別のentityパッケージとは配置が異なります。APIインターフェースはjp.jasminesoft.wagby.app.generated.apiパッケージです。
generate.shはOpenAPI定義の生成とOpenAPIによるソース生成も行います。EntityとDTOのアクセサ名を比較するときは、Entityのソースと、Mapperのimport先のDTOのソースをそれぞれ確認します。
生成ソースは再生成で更新されるため、直接修正せず、Javaカスタマイズはrestapi/src/main/customize/javaへ置きます。独自処理を組み込む方法は、カスタマイズを参照してください。
4. 参考資料
- モデルを作成する —
designer/docs/appschema/html/guide/03-model/01-create-model.html - エンティティ定義 —
designer/docs/appschema/html/reference/06-entity.html - コード生成規約 —
designer/docs/appschema/html/reference/internals/03-code-generation.html - Javaカスタマイズコード作成ガイド —
designer/docs/java/html/java-customization/index.html