このTipは@tcharlによって提出されました
生成コードとカスタム・コードの結合 パーマリンク to "生成コードとカスタム・コードの結合"
目標: Jhipsterは、その強力なドメイン固有言語のおかげで、モデルエンティティの管理に非常に適しています。 しかし、カスタムコードとジェネレーティブな世界の両方で最高のものを得ることは、常に困難な作業です。 ここでは、それを実現するために採用できるさまざまなパターンを紹介します。
パターン1 - 初回のみ生成 パーマリンク to "パターン1 - 初回のみ生成"
このアプローチは最も単純であり、ほとんどのユース・ケースで使用されます。 これは、エンティティを一度モデリングし、最初のモデルを生成し、この最初のショットの後に必要なものをオーバーライドすることで構成されます。 ある日再同期したい場合は、いつでも別のブランチで再生成でき、IDEで両方のコードを比較できます。 しかし、その後のプロセスは常に苦痛であり、大規模なアップグレードには何日もかかる可能性があります。
長所 パーマリンク to "長所"
- 好きなようにできます。
短所 パーマリンク to "短所"
- JHipsterの新機能の恩恵を受けられないことになります。
パターン2 - 生成コードとカスタムコードの分割 パーマリンク to "パターン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
長所 パーマリンク to "長所"
- 生成とカスタムコードを簡単に組み合わせることができます。
短所 パーマリンク to "短所"
- デッドコードが存在します。
- モデルとは異なる名前やパッケージを持つカスタムクラスが存在することになります（DDDのベストプラクティスと考えることができますが、それでも）。
パターン3 - サイド・バイ・サイド パーマリンク to "パターン3 - サイド・バイ・サイド"
ここでの目標は、クラス拡張とBeanの優先順位を使用して、生成されたコードの代わりにカスタム・コードを注入することです。
Customerjhipsterエンティティの例を見てみましょう。
リポジトリ パーマリンク to "リポジトリ"
リポジトリレベルでは、jhipsterが生成したリポジトリにNoRepositoryBeanアノテーションを使用してアノテーションを付け、検出を無効にします。
次に、カスタムリポジトリクラスを作成します。
@Repository
@Primary
MemberRepositoryPrimary extends MemberRepository
サービス パーマリンク to "サービス"
ここでは、ControllerにカスタムBeanを注入できるように、serviceImplオプションを使用します。
次に、生成されたサービスを単純に拡張し、優先順位を得るためにBeanに@Primaryというアノテーションを付けることができます。
コントローラ パーマリンク to "コントローラ"
カスタム・エンドポイントには別のAPIプレフィックスを使用します（例えば/api/v2）。
Angular パーマリンク to "Angular"
同じ拡張機能をフロントエンド側にも適用します。その後、app.module.tsファイルでBeanの優先順位を設定します。
providers: [
// 別のエントリをキープする
{ provide: MemberDomainService, useExisting: MemberDomainServicePrimary },
]
長所 パーマリンク to "長所"
- 生成されたコードの動作をオーバーライドできます。
- カスタムコードの検索が容易です。
- カスタムコードに対してもJhipsterのベストレイアウトを維持できます。
短所 パーマリンク to "短所"
- ファイルの重複が発生します。