アノテーションを変更するためにJavaでサブクラスを作成するのは悪い習慣と考えられますか?

たとえば、JPAやHibernateのコードを書くときには、ドメインクラスの子孫、例えばAccountを作成したいと思うかもしれません。下位バージョンは、ユーザーに表示されるフォームを表します。フォームには、アカウントにあるフィールドの約半分しかありません。したがって、私がフォームの値を保持するために使用するオブジェクトは、他のフィールドを変更すべきではありません。

アノテーションを変更する継承を使用していますか?そうではないとすれば、それをより効果的に、あるいはより効果的に行うための良い短い手やデザインパターンがありますか?

2

1 答え

私はあなたがここで説明したケース(少なくとも私がそれをどのように理解したか)は、サブクラスを作成するための良い候補ではないと言いたいと思います。

基本的には、エンティティの一部のフィールド/関連付けのみを変更するようにフォームを制限したいのですが、そうですか?私はさらに、フォームの開発者が編集可能なフィールドのみが変更されていると信じていないと仮定しているため、それを制限する必要があります。

その場合、 DTOパターン(データ転送オブジェクト)を使用することもできます。 DTOをフォームデータに追加し、ユーザーがそのフィールドに入力できるようにします。次に、DTOをサービスに渡します。サービスに応じてエンティティを更新します。この方法で、編集可能なフィールドと更新の実行方法を制御できます。

もう1つの方法は、編集不可能なフィールドのセッターが呼び出されたときに例外をスローするエンティティーのラッパーを作成することです。しかし、それは実行時の解決策であり、私はここでDTOのアプローチを好むだろう。

Edit:

この場合、継承が問題となる可能性がある理由はいくつかあります。

  • サブクラスはエンティティを表しませんが、データベース上のサブクラス(discriminatorsまたは追加のテーブルを使用して)を表現する必要があります。
  • そのフォームで作成されたエンティティは常にサブクラスを持つため、他の場所で編集することはできません(データベースなどが混乱しない限り)。
  • エンティティはデータコンテナであり、プレゼンテーションに依存してはいけません。したがって、1つのUI用の特殊なエンティティ(サブクラス)を使用すると、モデル/データとビュー/プレゼンテーションレイヤー間の単一責任の原則と抽象に違反することになります。
2
追加された