it-swarm.com.de

Hibernate-Anmerkungen - Welches ist der bessere Zugriff auf Felder oder Eigenschaften?

Diese Frage steht in gewissem Zusammenhang mit Hibernate Annotation Placement Question .

Aber ich möchte wissen, was besser ist? Zugriff über Eigenschaften oder Zugriff über Felder? Welche Vor- und Nachteile gibt es?

119
Martin OConnor

Ich bevorzuge Accessoren, da ich meinen Accessoren jederzeit Geschäftslogik hinzufügen kann, wenn ich es brauche ... Hier ein Beispiel:

@Entity
public class Person {

  @Column("nickName")
  public String getNickName(){
     if(this.name != null) return generateFunnyNick(this.name);
     else return "John Doe";
  }
}

Wenn Sie weitere Bibliotheken in den Mix werfen (wie zum Beispiel JSON-Konvertierungs-Bibliotheken oder BeanMapper oder Dozer oder andere Bean-Mapping-/Klonierungs-Libs, die auf Getter/Setter-Eigenschaften basieren), haben Sie die Garantie, dass die Lib mit der Persistenz synchron ist Manager (beide verwenden den Getter/Setter).

31
Miguel Ping

Es gibt Argumente für beide, aber die meisten ergeben sich aus bestimmten Benutzeranforderungen: "Was ist, wenn Sie Logik hinzufügen müssen" oder "xxxx unterbricht die Kapselung". Jedoch hat niemand die Theorie wirklich kommentiert und ein richtig begründetes Argument gegeben.

Was macht Hibernate/JPA eigentlich, wenn es ein Objekt persistiert? Nun, es persistiert den STATE des Objekts. Das heißt, es muss so aufbewahrt werden, dass es leicht reproduziert werden kann.

Was ist Verkapselung? Kapselung bedeutet, die Daten (oder den Status) mit einer Schnittstelle zu kapseln, über die die Anwendung/der Client sicher auf die Daten zugreifen kann - und diese konsistent und gültig zu halten.

Stellen Sie sich das wie MS Word vor. MS Word verwaltet ein Modell des Dokuments im Speicher - den Dokumentstatus. Es stellt eine Benutzeroberfläche zur Verfügung, mit der der Benutzer das Dokument ändern kann - eine Reihe von Schaltflächen, Werkzeugen, Tastaturbefehlen usw. Wenn Sie sich jedoch dafür entscheiden, dieses Dokument beizubehalten (zu speichern), wird der interne Status gespeichert, nicht die Reihe der Tastendrücke und Mausklicks, um es zu generieren.

Das Speichern des internen Zustands des Objekts unterbricht NICHT die Kapselung - andernfalls verstehen Sie nicht wirklich, was Kapselung bedeutet und warum sie existiert. Es ist wirklich wie bei der Objektserialisierung.

Aus diesem Grund ist es in den meisten Fällen angebracht, die FELDER und nicht die ZUBEHÖRTEILE beizubehalten. Dies bedeutet, dass ein Objekt genau so aus der Datenbank wiederhergestellt werden kann, wie es gespeichert wurde. Es sollte keine Validierung erforderlich sein, da dies mit dem Original beim Erstellen und vor dem Speichern in der Datenbank durchgeführt wurde (es sei denn, Gott bewahre, Sie speichern ungültige Daten in der Datenbank !!!!). Ebenso sollte es nicht erforderlich sein, Werte zu berechnen, da diese bereits vor dem Speichern des Objekts berechnet wurden. Das Objekt sollte genauso aussehen wie vor dem Speichern. Tatsächlich erhöhen Sie das Risiko, dass Sie etwas neu erstellen, das keine exakte Kopie des Originals ist, indem Sie den Gettern/Settern zusätzliches Material hinzufügen .

Natürlich wurde diese Funktionalität aus einem bestimmten Grund hinzugefügt. Es kann einige gültige Anwendungsfälle geben, um die Zugriffsmethoden beizubehalten, diese sind jedoch in der Regel selten. Ein Beispiel könnte sein, dass Sie vermeiden möchten, einen berechneten Wert beizubehalten, obwohl Sie möglicherweise die Frage stellen möchten, warum Sie ihn nicht bei Bedarf im Getter des Werts berechnen oder ihn im Getter träge initialisieren möchten. Persönlich kann ich mir keinen guten Anwendungsfall vorstellen, und keine der Antworten hier gibt wirklich eine "Software Engineering" -Antwort.

235
Martin

Ich bevorzuge Feldzugang, weil ich nicht gezwungen bin, Getter/Setter für jede Eigenschaft bereitzustellen.

Eine schnelle Umfrage bei Google legt nahe, dass der Feldzugriff die Mehrheit ist (z. B. http://Java.dzone.com/tips/12-feb-jpa-20-why-accesstype ).

Ich glaube, Feldzugang ist die von Spring empfohlene Redewendung, aber ich kann keinen Hinweis finden, der das bestätigt.

Es gibt eine verwandte SO - Frage , die die Leistung zu messen versuchte und zu dem Schluss kam, dass es "keinen Unterschied" gibt.

76
duffymo

Hier ist eine Situation, in der Sie Eigenschaftszugriffsmittel verwenden MÜSSEN. Stellen Sie sich vor, Sie haben eine abstrakte GENERIC-Klasse mit viel Implementierungsgüte, die Sie in 8 konkrete Unterklassen übernehmen können:

public abstract class Foo<T extends Bar> {

    T oneThing;
    T anotherThing;

    // getters and setters ommited for brevity

    // Lots and lots of implementation regarding oneThing and anotherThing here
 }

Wie genau solltest du diese Klasse kommentieren? Die Antwort lautet: SIE KÖNNEN es nicht mit Feld- oder Eigenschaftszugriff kommentieren, da Sie die Zieleinheit an dieser Stelle nicht angeben können. Sie MÜSSEN die konkreten Implementierungen mit Anmerkungen versehen. Da die persistenten Eigenschaften jedoch in dieser Oberklasse deklariert sind, MÜSSEN Sie den Eigenschaftszugriff in den Unterklassen verwenden.

Der Feldzugriff ist in einer Anwendung mit abstrakten generischen Superklassen nicht möglich.

37
HDave

Ich neige dazu, Property Accessor zu bevorzugen und zu verwenden:

  • Ich kann Logik hinzufügen, wenn die Notwendigkeit entsteht (wie in der akzeptierten Antwort erwähnt).
  • damit kann ich foo.getId()aufrufen, ohne einen Proxy zu initialisieren (wichtig bei der Verwendung von Hibernate, bis HHH-3718 get aufgelöst wird).

Nachteil:

  • dadurch wird der Code weniger lesbar. Sie müssen beispielsweise eine ganze Klasse durchsuchen, um zu sehen, ob dort @Transient vorhanden ist.
33
Pascal Thivent

Das hängt wirklich von einem bestimmten Fall ab - beide Optionen stehen aus einem bestimmten Grund zur Verfügung. IMO läuft es auf drei Fälle:

  1. setter hat eine Logik, die zum Zeitpunkt des Ladens einer Instanz aus einer Datenbank nicht ausgeführt werden sollte; Zum Beispiel wird im Setter einige Wertevalidierung durchgeführt, die Daten, die von db stammen, sollten jedoch gültig sein (andernfalls würden sie nicht dorthin gelangen (:);
  2. setter hat eine Logik, die immer aufgerufen werden sollte, selbst wenn eine Instanz aus db geladen wird. Zum Beispiel wird die Eigenschaft, die initialisiert wird, bei der Berechnung eines berechneten Feldes verwendet (z. B. Eigenschaft - ein Geldbetrag, eine berechnete Eigenschaft - eine Summe mehrerer monetärer Eigenschaften der gleichen Instanz); In diesem Fall ist der Zugriff auf die Immobilie erforderlich.
  3. Keiner der oben genannten Fälle - dann sind beide Optionen anwendbar. Bleiben Sie einfach konsistent (z. B. wenn der Feldzugriff in dieser Situation die Wahl ist, und verwenden Sie ihn in einer ähnlichen Situation ständig).
13
01es

Ich würde den Feldzugriff und NICHT Anmerkungen auf den Get-Geräten (Eigenschaftszugriff) dringend empfehlen, wenn Sie mehr als nur den Wert festlegen möchten (z. B. Verschlüsselung oder Berechnung). 

Das Problem beim Eigenschaftszugriff besteht darin, dass die Setter auch beim Laden des Objekts aufgerufen werden. Dies hat für viele Monate gut funktioniert, bis wir die Verschlüsselung einführen wollten. In unserem Anwendungsfall wollten wir ein Feld im Setter verschlüsseln und im Getter entschlüsseln. Das Problem beim Eigenschaftszugriff bestand nun darin, dass beim Laden des Objekts durch Hibernate auch der Setter aufgerufen wurde, um das Feld aufzufüllen, und der verschlüsselte Wert damit erneut verschlüsselt wurde. In diesem Beitrag wird auch Folgendes erwähnt: Java Hibernate: Unterschiedliches Verhalten der Eigenschaftssatzfunktion, abhängig davon, wer sie aufruft

Dies hat mir Kopfschmerzen bereitet, bis ich mich an den Unterschied zwischen Feldzugriff und Grundstückszugriff erinnerte. Jetzt habe ich alle meine Anmerkungen vom Eigenschaftszugriff auf den Feldzugriff verschoben und es funktioniert jetzt einwandfrei. 

12
Christoph

Ich ziehe aus folgenden Gründen den Feldzugang vor:

  1. Die Eigenschaft property access kann bei der Implementierung von equals/hashCode und referenzierenden Feldern (im Gegensatz zu ihren Gettern) zu sehr bösen Fehlern führen. Dies liegt daran, dass der Proxy nur beim Zugriff auf die Getter initialisiert wird und ein Direktfeldzugriff einfach Null zurückgibt.

  2. Für die Eigenschaft property access müssen Sie alle Utility-Methoden (z. B. addChild/removeChild) als @Transient angeben.

  3. Mit dem Feldzugriff können Sie das @Version-Feld ausblenden, indem Sie keinen Getter freigeben. Ein Getter kann auch dazu führen, dass ein Setter hinzugefügt wird, und das version-Feld sollte niemals manuell gesetzt werden (was zu sehr unangenehmen Problemen führen kann). Alle Versionsinkrementierungen sollten durch OPTIMISTIC_FORCE_INCREMENT oder PESSIMISTIC_FORCE_INCREMENT explizites Sperren ausgelöst werden.

8
Vlad Mihalcea

Ich denke, das Annotieren der Eigenschaft ist besser, da das Aktualisieren von Feldern die Kapselung direkt unterbricht, selbst wenn Ihr ORM dies tut.

Hier ist ein großartiges Beispiel dafür, wo Sie verbrannt werden: Wahrscheinlich möchten Sie Ihre Anmerkungen für den Hibernate-Validierer und die Persistenz an derselben Stelle (entweder Felder oder Eigenschaften). Wenn Sie die Validierungen des Hibernate-Validators testen möchten, die auf einem Feld mit Anmerkungen versehen sind, können Sie nicht einen Mock Ihrer Entität verwenden, um Ihren Gerätetest nur vom Validator zu isolieren. Autsch.

7
Justin Standard

Meines Erachtens unterscheidet sich der Zugriff von Immobilien gegenüber Feldzugriff in Bezug auf die langsame Initialisierung.

Beachten Sie die folgenden Zuordnungen für 2 grundlegende Beans:

<hibernate-mapping package="org.nkl.model" default-access="field">
  <class name="FieldBean" table="FIELD_BEAN">
    <id name="id">
      <generator class="sequence" />
    </id>
    <property name="message" />
  </class>
</hibernate-mapping>

<hibernate-mapping package="org.nkl.model" default-access="property">
  <class name="PropBean" table="PROP_BEAN">
    <id name="id">
      <generator class="sequence" />
    </id>
    <property name="message" />
  </class>
</hibernate-mapping>

Und die folgenden Unit-Tests:

@Test
public void testFieldBean() {
    Session session = sessionFactory.openSession();
    Transaction tx = session.beginTransaction();
    FieldBean fb = new FieldBean("field");
    Long id = (Long) session.save(fb);
    tx.commit();
    session.close();

    session = sessionFactory.openSession();
    tx = session.beginTransaction();
    fb = (FieldBean) session.load(FieldBean.class, id);
    System.out.println(fb.getId());
    tx.commit();
    session.close();
}

@Test
public void testPropBean() {
    Session session = sessionFactory.openSession();
    Transaction tx = session.beginTransaction();
    PropBean pb = new PropBean("prop");
    Long id = (Long) session.save(pb);
    tx.commit();
    session.close();

    session = sessionFactory.openSession();
    tx = session.beginTransaction();
    pb = (PropBean) session.load(PropBean.class, id);
    System.out.println(pb.getId());
    tx.commit();
    session.close();
}

Sie werden den geringfügigen Unterschied in den erforderlichen Einstellungen sehen:

Hibernate: 
    call next value for hibernate_sequence
Hibernate: 
    insert 
    into
        FIELD_BEAN
        (message, id) 
    values
        (?, ?)
Hibernate: 
    select
        fieldbean0_.id as id1_0_,
        fieldbean0_.message as message1_0_ 
    from
        FIELD_BEAN fieldbean0_ 
    where
        fieldbean0_.id=?
0
Hibernate: 
    call next value for hibernate_sequence
Hibernate: 
    insert 
    into
        PROP_BEAN
        (message, id) 
    values
        (?, ?)
1

Das heißt, der Aufruf von fb.getId() erfordert eine Auswahl, wohingegen pb.getId() dies nicht tut.

6
toolkit

Ich bevorzuge Feldzugriffe. Der Code ist viel sauberer. Alle Anmerkungen können in einem -Abschnitt einer Klasse platziert werden, und der Code ist viel einfacher zu lesen. 

Ich habe ein anderes Problem mit Property-Accessoren gefunden: Wenn Sie über getXYZ-Methoden für Ihre Klasse verfügen, die NICHT mit permanenten Eigenschaften verknüpft sind, generiert der Ruhezustand sql, um diese Eigenschaften abzurufen, was zu sehr verwirrenden Fehlermeldungen führt. Zwei Stunden verschwendet. Ich habe diesen Code nicht geschrieben; Ich habe in der Vergangenheit immer Feldzugriffspunkte verwendet und bin nie auf dieses Problem gestoßen.

In dieser App verwendete Ruhezustand-Versionen:

<!-- hibernate -->
<hibernate-core.version>3.3.2.GA</hibernate-core.version>
<hibernate-annotations.version>3.4.0.GA</hibernate-annotations.version>
<hibernate-commons-annotations.version>3.1.0.GA</hibernate-commons-annotations.version>
<hibernate-entitymanager.version>3.4.0.GA</hibernate-entitymanager.version>
2
John Goyer

Sind wir schon da

Dies ist eine alte Präsentation, aber Rod schlägt vor, dass Annotationen beim Zugriff auf Eigenschaften anämische Domänenmodelle fördern und nicht als Standardmethode für Annotationen dienen sollten.

2
Manuel Palacio

Ich bevorzuge Felder, aber ich bin in eine Situation geraten, die mich zwingt, die Anmerkungen auf Getigern zu platzieren.

Mit der Hibernate-JPA-Implementierung scheint @Embedded bei Feldern nicht zu funktionieren. Das muss auf den Getter gehen. Und sobald Sie das auf den Getter gesetzt haben, müssen auch die verschiedenen @Column-Annotationen auf die Getter gehen. (Ich denke, Hibernate möchte hier keine Felder und Getter mischen.) Und wenn Sie einmal @Column auf Getter in einer Klasse setzen, ist es wahrscheinlich sinnvoll, dies überall zu tun.

2
Willie Wheeler

Standardmäßig greifen JPA-Provider auf die Werte von Entitätsfeldern zu und ordnen diese Felder den Datenbankspalten Mit den JavaBean-Eigenschaftszugriffsmethoden (Getter) und Mutator (Setter) der Entität zu. Die Namen und Typen der privaten Felder in einer Entität sind für JPA daher unerheblich. Stattdessen prüft JPA nur die Namen und Rückgabetypen der JavaBean-Eigenschafts-Accessoren. Sie können dies mit der Annotation @javax.persistence.Access ändern, mit der Sie explizit angeben können, welche Zugriffsmethode der JPA-Anbieter verwenden soll.

@Entity
@Access(AccessType.FIELD)
public class SomeEntity implements Serializable
{
...
}

Die verfügbaren Optionen für die AccessType-Enumeration sind PROPERTY (Standardeinstellung) und FIELD. MitPROPERTY ruft der Provider Feldwerte ab und legt sie mit den JavaBean-Eigenschaftsmethoden fest. FIELD bewirkt, dass der Provider Feldwerte mithilfe der Instanzfelder abruft und festlegt. Als bewährte Methode sollten Sie einfach die Standardeinstellung beibehalten und die JavaBean-Eigenschaften verwenden, es sei denn, Sie haben einen zwingenden Grund, etwas anderes zu tun.

Sie können diese Eigenschaftsanmerkungen entweder in den privaten Feldern oder den öffentlichen Zugriffsmethoden ablegen. Wenn Sie AccessType.PROPERTY (Standard) verwenden und die privaten Felder anstelle der JavaBean -Accessoren mit Anmerkungen versehen, müssen die Feldnamen mit den JavaBean-Eigenschaftsnamen übereinstimmen. Die Namen müssen jedoch nicht übereinstimmen, wenn Sie die JavaBean-Accessoren mit Anmerkungen versehen. Wenn Sie anstelle der Felder AccessType.FIELD und Die JavaBean-Zugriffsmethoden verwenden, müssen die Feldnamen ebenfalls mit den Namen der JavaBean -Eigenschaft übereinstimmen. In diesem Fall müssen sie nicht übereinstimmen, wenn Sie die Felder mit Anmerkungen versehen. Es ist am besten, die JavaBean-Zugriffsmethoden für AccessType.PROPERTY und die Felder für AccessType.FIELD zu vereinheitlichen und mit Anmerkungen zu versehen.

Es ist wichtig, dass Sie niemals JPA-Eigenschaftsanmerkungen und JPA-Feldanmerkungen in derselben Entität mischen. Andernfalls führt dies zu einem nicht angegebenen Verhalten und es ist sehr wahrscheinlich, dass es Fehler gibt.

2
Faraz Durrani

Ein weiterer Punkt zugunsten des Feldzugriffs ist, dass Sie andernfalls Setter für Sammlungen anzeigen müssen, was für mich eine schlechte Idee ist, da das Ändern der persistenten Sammlungsinstanz in ein Objekt, das nicht von Hibernate verwaltet wird, definitiv Ihre Datenkonsistenz beeinträchtigt.

Ich ziehe es vor, Sammlungen als geschützte Felder initialisiert zu haben, um Implementierungen im Standardkonstruktor zu leeren und nur deren Getter freizulegen. Dann sind nur verwaltete Vorgänge wie clear(), remove(), removeAll() usw. möglich, durch die der Hibernate-Server niemals Änderungen bemerkt wird.

2

Sie sollten den Zugriff über Felder über den Zugriff über die Eigenschaften ..__ auswählen. Mit Feldern können Sie die gesendeten und empfangenen Daten einschränken . Mit den Eigenschaften können Sie weitere Daten als Host senden und .__ die meisten Eigenschaften insgesamt festlegen).

2
user10801787

Ich habe die faule Initialisierung und den Feldzugriff hier gelöst Hibernate Eins-zu-Eins: getId () ohne das gesamte Objekt abzurufen

1
xmedeko

Ich hatte die gleiche Frage bezüglich accesstype im Winterschlaf und fand einige Antworten hier .

1
sundary

Wir haben Entity-Beans erstellt und Getter-Annotationen verwendet. Das Problem, auf das wir stießen, ist folgendes: Einige Entitäten haben komplexe Regeln für einige Eigenschaften, wann sie aktualisiert werden können. Die Lösung bestand darin, in jedem Setter eine Geschäftslogik zu verwenden, die bestimmt, ob der tatsächliche Wert geändert wurde oder nicht, und falls ja, ob die Änderung zulässig sein sollte. Natürlich kann Hibernate die Eigenschaften immer festlegen, so dass wir zwei Gruppen von Setzern hatten. Ziemlich hässlich.

Beim Lesen der vorherigen Beiträge sehe ich auch, dass der Verweis auf die Eigenschaften innerhalb der Entität zu Problemen führen kann, wenn Sammlungen nicht geladen werden.

Unterm Strich würde ich mich dazu neigen, die Felder in Zukunft zu kommentieren.

1
Steve11235

ich denke darüber nach und wähle die Methode accesor 

warum? 

da field und methos accesor gleich sind Wenn ich später etwas logik im load-Feld brauche, speichere ich alle Anmerkungen in Feldern

grüße

Grubhart

0
user261548

Normalerweise sind Beans POJO, also haben sie sowieso Zugriffsmethoden. 

Die Frage ist also nicht "welches ist besser?", Sondern einfach "wann Feldzugang?". Und die Antwort ist "wenn Sie keinen Setter/Getter für das Feld brauchen!".

0

Lassen Sie mich versuchen, die wichtigsten Gründe für die Wahl des feldbasierten Zugriffs zusammenzufassen. Wenn Sie tiefer eintauchen möchten, lesen Sie bitte diesen Artikel in meinem Blog: Zugriffsstrategien in JPA und Hibernate - Was ist besser, Zugriff auf Felder oder Eigenschaften?

Der feldbasierte Zugriff ist bei weitem die bessere Option. Hier sind 5 Gründe dafür:

Grund 1: Bessere Lesbarkeit Ihres Codes

Wenn Sie den feldbasierten Zugriff verwenden, kommentieren Sie Ihre Entitätsattribute mit Ihren Mapping-Anmerkungen. Wenn Sie die Definition aller Entitätsattribute ganz oben in Ihrer Klasse platzieren, erhalten Sie eine relativ kompakte Ansicht aller Attribute und ihrer Zuordnungen.

Grund 2: Getter- oder Setter-Methoden auslassen, die von Ihrer Anwendung nicht aufgerufen werden sollten

Ein weiterer Vorteil des feldbasierten Zugriffs besteht darin, dass Ihr Persistenzanbieter, z. B. Hibernate oder EclipseLink, die Getter- und Setter-Methoden Ihrer Entitätsattribute nicht verwendet. Das bedeutet, dass Sie keine Methode angeben müssen, die von Ihrem Geschäftscode nicht verwendet werden sollte. Dies ist meistens der Fall bei Setter-Methoden von generierten Primärschlüsselattributen oder Versionsspalten. Ihr Persistenzanbieter verwaltet die Werte dieser Attribute, und Sie sollten sie nicht programmgesteuert festlegen.

Grund 3: Flexible Implementierung von Getter- und Setter-Methoden

Da Ihr Persistenzanbieter die Getter- und Setter-Methoden nicht aufruft, müssen sie keine externen Anforderungen erfüllen. Sie können diese Methoden auf beliebige Weise implementieren. Dadurch können Sie geschäftsspezifische Validierungsregeln implementieren, zusätzliche Geschäftslogik auslösen oder das Entitätsattribut in einen anderen Datentyp konvertieren.

Sie können dies zum Beispiel verwenden, um eine optionale Verknüpfung oder ein optionales Attribut in ein Java-Optional-Objekt einzugeben.

Grund 4: Keine Notwendigkeit, Hilfsmittel als @Transient zu kennzeichnen

Ein weiterer Vorteil der feldbasierten Zugriffsstrategie ist, dass Sie Ihre Dienstprogrammmethoden nicht mit @Transient versehen müssen. Diese Anmerkung weist Ihren Persistenzanbieter an, dass eine Methode oder ein Attribut nicht Teil des persistenten Status der Entität ist. Und da beim Feldtypzugriff der permanente Status durch die Attribute Ihrer Entität definiert wird, ignoriert Ihre JPA-Implementierung alle Methoden Ihrer Entität.

Grund 5: Vermeiden Sie Fehler beim Arbeiten mit Proxys

Hibernate verwendet Proxies für lazily to-one-Assoziationen , um die Initialisierung dieser Assoziationen zu steuern. Dieser Ansatz funktioniert in fast allen Situationen gut. Es führt jedoch zu einer gefährlichen Gefahr, wenn Sie den objektbasierten Zugriff verwenden.

Wenn Sie den auf Eigenschaften basierenden Zugriff verwenden, initialisiert Hibernate die Attribute des Proxy-Objekts, wenn Sie die Getter-Methode aufrufen. Dies ist immer der Fall, wenn Sie das Proxy-Objekt in Ihrem Geschäftscode verwenden. Auf equals und hashCode-Implementierungen kann jedoch auf die Attribute direkt zugegriffen werden. Wenn Sie zum ersten Mal auf eines der Proxy-Attribute zugreifen, sind diese Attribute noch nicht initialisiert.

0
Thorben Janssen

Um Ihre Klassen sauberer zu machen, fügen Sie die Anmerkung in das Feld ein und verwenden Sie @Access (AccessType.PROPERTY)

0
ely

Beide : 

Die EJB3-Spezifikation erfordert, dass Sie dem Element .__ Anmerkungen hinzufügen. Typ, auf den zugegriffen wird, d. h. die Getter-Methode, wenn Sie die Eigenschaft .__ verwenden. access, das Feld, wenn Sie den Feldzugriff verwenden.

https://docs.jboss.org/hibernate/annotations/3.5/reference/en/html_single/#entity-mapping

0
moueza

AccessType.PROPERTY: Die EJB-Persistenzimplementierung lädt den Status über JavaBean-Methode "setter" in Ihre Klasse und ruft den Status mit JavaBean-Methode "getter" von Ihrer Klasse ab. Dies ist die Standardeinstellung.

AccessType.FIELD: State wird geladen und direkt aus den Feldern Ihrer Klasse abgerufen. Sie müssen keine JavaBean-"Getter" und "Setter" schreiben.

0
Vicky