4

DB にマップされていないフィールドを追加すると、エンティティ クラスが破損し、問題を解決する間違った方法であるという、哲学的な直感的な感覚があります。

@Transientしかし、フィールドの使用が暗黙的で難しい問題を解決する具体的な状況はありますか?

たとえば、@Transientエンティティにフィールドがある場合、第 2 レベルのキャッシュを追加または削除するとアプリが壊れる可能性はありますか?

かなりの更新：フィールドについていくつか考えた後、フィールドは適切な方法で使用する必要がある@Transientように思えます。@Transient

「適切な方法」とは、エンティティが常に同じ動作をする必要があることを意味します。nullこれは、 @Transient フィールドの値に応じて getter が を時々返すときに、非常にエラーが発生しやすい動作であることを意味します。また、@Transient フィールドは常に初期化する必要があることを意味します。

そして、適切な使用例は2つしかありません。

  1. @Transient フィールドは、オブジェクトのコンストラクターで初期化する必要があります。

    @Entity
public class SomeEntity
   @Id
   private long id;

   @Transient
   private String transientField;

   public SomeEntity () {
      transientField = "some string";
   }       
   ...
}

  2. @Transient フィールドは遅延初期化できます。

    @Entity
public class SomeEntity
   @Id
   private long id;

   @Transient
   private String transientField;

   public String getTransientField () {
      synchronized (lock) {
         if (transientField == null) {
            transientField = "some string";
         }   
      }
      return transientField;
   }       
   ...
}

誰かがこれらの 2 つのケースについてコメントしたり、私が見逃した他のケースについて説明したりできますか?

4

1 に答える 1

1

ハイバネートでも持続するいくつかのプロジェクトで Transient アノテーションを使用していますが、まだ問題はありません。

これは通常、他の永続プロパティによって決定できるフィールドに使用され、キャッシュの使用も機能するはずです。これは、Java のシリアライゼーション メカニズム (キャッシュは通常、キャッシュされたオブジェクトがシリアライズ可能であることを期待する) も Transient アノテーションを考慮に入れるためです。可能な限り、インスタンス フィールドの代わりに情報を提供する一時的な getter および setter プロパティを使用することが望ましいと思います。

于 2010-05-28T11:28:20.963 に答える