このTipは@tcharlによって提出されました

生成コードとカスタム・コードの結合

目標: Jhipsterは、その強力なドメイン固有言語のおかげで、モデルエンティティの管理に非常に適しています。 しかし、カスタムコードとジェネレーティブな世界の両方で最高のものを得ることは、常に困難な作業です。 ここでは、それを実現するために採用できるさまざまなパターンを紹介します。

パターン1 - 初回のみ生成

このアプローチは最も単純であり、ほとんどのユース・ケースで使用されます。 これは、エンティティを一度モデリングし、最初のモデルを生成し、この最初のショットの後に必要なものをオーバーライドすることで構成されます。 ある日再同期したい場合は、いつでも別のブランチで再生成でき、IDEで両方のコードを比較できます。 しかし、その後のプロセスは常に苦痛であり、大規模なアップグレードには何日もかかる可能性があります。

長所

• 好きなようにできます。

短所

• JHipsterの新機能の恩恵を受けられないことになります。

パターン2 - 生成コードとカスタムコードの分割

これは、生成されたクラスを変更するのを避け、カスタム・コードを専用のものとして立てるようにします。 ここでは、--with-generated-flagのjhipster cliオプションを使用して、生成されたクラスとカスタムクラスを簡単に区別できます。 最後に、生成されたホームページではなくカスタムホームページにルーティングするために、フロントエンド部分のメインルーターを変更するだけです。

ルータファイルが世代ごとに上書きされるのを避けるために、プロジェクトのルートに.yo-resolveファイルを作成して、yeomanに期待される動作を伝えることができます。

例：

src/main/resources/swagger/api.yml skip
src/main/webapp/app/modules/home/home.tsx skip

長所

• 生成とカスタムコードを簡単に組み合わせることができます。

短所

• デッドコードが存在します。
• モデルとは異なる名前やパッケージを持つカスタムクラスが存在することになります（DDDのベストプラクティスと考えることができますが、それでも）。

パターン3 - サイド・バイ・サイド

ここでの目標は、クラス拡張とBeanの優先順位を使用して、生成されたコードの代わりにカスタム・コードを注入することです。

Customerjhipsterエンティティの例を見てみましょう。

リポジトリ

リポジトリレベルでは、jhipsterが生成したリポジトリにNoRepositoryBeanアノテーションを使用してアノテーションを付け、検出を無効にします。 次に、カスタムリポジトリクラスを作成します。

@Repository
@Primary
MemberRepositoryPrimary extends MemberRepository

サービス

ここでは、ControllerにカスタムBeanを注入できるように、serviceImplオプションを使用します。 次に、生成されたサービスを単純に拡張し、優先順位を得るためにBeanに@Primaryというアノテーションを付けることができます。

コントローラ

カスタム・エンドポイントには別のAPIプレフィックスを使用します（例えば/api/v2）。

Angular

同じ拡張機能をフロントエンド側にも適用します。その後、app.module.tsファイルでBeanの優先順位を設定します。

providers: [
// 別のエントリをキープする
{ provide: MemberDomainService, useExisting: MemberDomainServicePrimary },
]

長所

• 生成されたコードの動作をオーバーライドできます。
• カスタムコードの検索が容易です。
• カスタムコードに対してもJhipsterのベストレイアウトを維持できます。

短所

• ファイルの重複が発生します。