2010-05-28 1 views
5

나는 철학 DB에 매핑되지 않은 필드를 추가하면 엔티티 클래스가 손상되고 문제를 해결하는 잘못된 방법이라는 직관적 인 느낌이 있습니다.엔티티에 @Transient annotation으로 표시된 필드를 추가하는 것은 버그가 발생하기 쉽습니다. 내가 맞습니까?

@Transient 필드를 사용하면 암시 적 및 하드 수정 문제가 발생하는 구체적인 상황이 있습니까?

예를 들어, 엔티티에 @Transient 개의 필드가있을 때 2 차 캐시를 추가하거나 제거하면 앱이 중단 될 수 있습니까?

상당한 갱신는 : @Transient 분야에 대한 몇 가지 생각 후에는 @Transient 필드 그냥 적절한 방법으로 사용되어야한다는 것을 나에게 보인다.

'적절한 방법'이란 엔티티가 항상 동일한 동작을 가져야 함을 의미합니다. getters가 @Transient 필드 값에 따라 때때로 null을 반환 할 때 오류가 발생하기 쉽습니다. 그리고 그것은 @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 건의 사례를 언급하거나 내가 놓친 다른 사례를 설명 할 수 있습니까?

+2

"철학적"이라고 말하면 "직관적"입니까? –

답변

1

최대 절전 모드에서도 지속되며 아직 문제가없는 일부 프로젝트에서는 일시적 주석을 사용하고 있습니다.

일반적으로 Javas 직렬화 메커니즘 (캐시는 캐시 된 객체가 직렬화 될 것으로 예상되기 때문에)은 다른 영구 속성에 의해 결정될 수있는 필드에 사용되며 캐시도 사용해야합니다. Transient 주석도 고려해야합니다. 가능한 경우 인스턴스 필드 대신 정보를 제공하는 일시적인 getter 및 setter 속성을 사용하는 것이 더 바람직하다고 생각합니다.