Dlaczego ktoś powinien umieszczać adnotacje na geterach lub seterach, gdy używa JPA do mapowania klas?

Dlaczego ktoś powinien umieszczać adnotacje na geterach lub seterach, gdy używa JPA do mapowania klas?

Jak już wspomniano, użycie właściwości access pozwala dodać logikę w getterze, jeśli zajdzie taka potrzeba.

Ale skoro pytanie jest oznaczone hibernate , wspomnę jeszcze o innym (huge) benefit: property access pozwala na wywołanie foo.getId() bez inicjowania proxy. Nie można uzyskać takiego samego zachowania podczas korzystania z dostępu do pola. Emmanuel Bernard wyjaśnia to ograniczenie dostępu do pola w następujący sposób:

To niefortunne, ale oczekiwane. To jedno z ograniczeń dostępu na poziomie pola. Zasadniczo nie mamy sposobu, aby wiedzieć, że getId() rzeczywiście tylko przejść i uzyskać dostęp do pola id. Więc musimy załadować cały obiekt, aby być bezpiecznym.

Więc tak, korzystanie z dostępu do właściwości utrudnia odczyt kodu, musisz na przykład przejrzeć całą klasę, aby sprawdzić, czy w pobliżu są jakieś @Transient. Ale dla mnie, korzyść (przynajmniej z hibernate) zdecydowanie przewyższa tę wadę.

Podobne pytania

• adnotacje Hibernate - co jest lepsze, dostęp do pól czy właściwości?
• Hibernate generowanie zapytań SQL podczas uzyskiwania dostępu do identyfikatora podmiotu powiązanego

Referencje

• Proxy ładowane na wywołanie getId podczas używania adnotacji na polach
• proxy getId = > dlaczego SQL jest generowany !
• HHH-3718

Podane odpowiedzi są poprawne. Adnotacja metod zamiast właściwości daje:

1. Prawo do użycia getId (), jeśli jest oznaczona jako wartość @ Id, aby uzyskać wartość klucza obcego z obiektu proxy bez ładowania go z DB.

2. Można tworzyć gettery / settery, które aktualizują wewnętrzny stan obiektu, który nie znajduje się w bazie danych. Użyłem tego podczas pobierania skompresowanego stanu z DB, który chcę zdekompresować wewnątrz obiektu do bardziej użytecznego wewnętrzne dane członków. Setters i getters ustawiają i pobierają stan skompresowany, a DB i Hibernate nie "wiedzą" o nieskompresowanym członie wewnętrznym.

Jest jedna wada, którą trafiłem:

A. Twoje setery muszą być dość proste. Hibernate oczekuje, że zrobi to, co zostanie osiągnięte przez bezpośrednie przypisanie do punktu odniesienia członka. Metoda "setCategory", która nie tylko ustawia kategorię, ale także aktualizuje odpowiedni obiekt kategorii, aby pokazać związek, może uzyskać masz kłopoty.

Używam adnotacji w getters / setters, ponieważ mam API oddzielone od implementacji i chciałem, aby część API była całkowicie wolna od frameworków, umożliwiając mi przełączanie frameworków lub dostarczanie różnych implementacji. Na przykład, w tej chwili używam spring-data-jpa, ale z poniższym API mogę łatwo przełączyć się na spring-jdbc lub inny framework.

To, co zrobiłem, to zdefiniowanie interfejsów dla kontrolera, repozytorium i encji, jako takie:

public interface MyEntityController<T extends MyEntity> {
    Iterable<T> listEntities();
    T getEntity(Long id);
}

public interface MyEntityService<T extends MyEntity> {
    Iterable<T> findAll();
    T findById(Long id);
}

public interface MyEntityRepository<T extends MyEntity> {
    Iterable<T> findAll();
    T findOne(Long id);
}

// no JPA annotations here
public abstract class MyEntity {
    protected Long id;
    protected String myField;
}

Następnie implementuję MyEntity w następujący sposób i używam MyEntityImpl dla implementacji kontrolera, usługi i repozytorium:

@Entity
public class MyEntityImpl extends MyEntity {
    @Id public long getId() { return id; }
    @Column public String getMyField() { return myField };
    // setters, etc
}

@Repository
public interface MyEntityRepositoryImpl extends MyEntityRepository, JPARepository<MyEntityImpl, Long> {
}

Już go przetestowałem i działa dobrze. Samo przypisanie MyEntityImpl z @Entity nie zadziałałoby, ponieważ Klasa nadrzędna musiałaby być @MappedSuperclass.