Annotation an felder oder methoden setzten?

[nimo22]

Hallo,

wie ist es besser:

so:

...
@Id
@Column(name = "ID_PERSON", nullable = false)
private Integer idPerson;
...

oder so:

...
@Id
@Column(name = "ID_PERSON", nullable = false)   
public Integer getIdPerson() {
        return idPerson;
    }
public void setIdUser(Integer idPerson) {
        this.idPerson = idPerson;
    }
...

Was macht das für einen Unterschied? Ist das eine besser (sicherer, schnelller, etc..) als das andere?

dank vorab.

 

[byte]

In der JPA Spec steht, man soll den Property AccessType nehmen (also an Gettern), aber keine Ahnung warum. Hibernate unterstützt beides (Property oder Field Access). Wenn man nix spezielles angibt, dann guckt Hibernate, wo @Id definiert ist und nimmt dann das als AccessType. Man sollte es also keinesfalls mischen, kann mit @AccessType aber auch spezielle Angaben machen.

 

[SnooP]

Ich würde grundsätzlich dem Vorschlag der JPA nehmen... sprich schreib es an die get-Methode.

 

[maki]

Weis jemand warim Hibernate/JPA die getter zu den eigntlichen Attributen bevorzugt?

Hätte es umgekehrt erwartet...

 

[nimo22]

wieso umgekehrt erwartet??

Was is nun besser??

wenn man die fields nimmt, braucht man doch dann keine getter-setter-methoden mehr..is au a bissl performanter, felder abzufragen bzw. zu ändern, statt jedesmal get oder set aufzurufen..oder irre ich mich da?

 

[ms]

Eigene Immutable-Types zB, wo es keine Getter und Setter gibt, wird man wohl mit Field-Access persistieren.

@nimo22
Public Members sind böse!
Performancemässig ist es denke ich irrelevant, da in beiden Fällen per Reflection zugefriffen wird.

ms

 

[nimo22]

public members? fields sind alle private deklariert...

brauch ich dann getters-setters, wenn ich Field-Access hab???

Unter forum.java.sun.com/thread.jspa?threadID=5199780&messageID=9795013
wird Field-Access bevorzugt.

 

[maki]

Beim persitieren geht es doch darum, den internen Zustand eines Objektes zu speichern...

Hab letztens gelesen, dass JDO Standardmässig über die Felder geht, Hibernate macht es umgekehrt.

Muss zugeben dass in meinen Hibernate Projekten immer über getter und setter gegangen bin, selbst wenn das bedeutete einen getter/setter nur dafür hinzuzufügen, nicht so schön was die Kapselung betrifft.

 

[nimo22]

wieso kapselung?

wenn ich über die felder geh, brauch ich doch dann keine getter-setter?!?

Weniger Code-Müll?

 

[maki]

wenn ich über die felder geh, brauch ich doch dann keine getter-setter?!?

Richtig.

Aber wie gesagt, bis jetzt habe ich es immer über Getter/Setter gemacht anstatt über die Felder, dazu braucht man eben Getter/Setter, wenn diese nur von hibernate genutzt werden sollen, habe ich damit die Kapselung durchbrochen..

 

[byte]

Aber wie gesagt, bis jetzt habe ich es immer über Getter/Setter gemacht anstatt über die Felder, dazu braucht man eben Getter/Setter, wenn diese nur von hibernate genutzt werden sollen, habe ich damit die Kapselung durchbrochen..

Du kannst wahlweise Getter/Setter aber auch private setzen. Dann ist die Kapselung wieder hergestellt.
Ich benutze atm Field Access, habe aber trotzdem Getter/Setter für alle Member, die wahlweise private sind (z.b. Setter für ID).

Warum ich Field Access benutze? Ich finde es einfach praktischer, weil ich die Mapping Annotations dann auf einen Blick sehe und nicht immer erst umständlich den Getter suchen muss, wenn ich das Mapping anpasse. Solange ich keine klaren Vorteile von Property Access sehe, mache ich das so weiter.

 

[Guest]

Ganz klar bei den Attributen, nicht bei Methoden. Allein schon aus dem simplen Grund, dass Getter und Setter nicht
immer Sinn machen oder gar dazu verleiten, die Interna einer Klasse ausserhalb der Klasse zu manipulieren.
Typisches Beispiel wäre die Komposition. Warum Getter für Collections anbieten, die nur innerhalb der Hauptentität
verwaltet werden und z.B. in anderer Form nach Aussen wiedergegeben werden?
Ausserden ist es, wie byto bereits geschrieben hat, um einiges übersichtlicher, wenn alle Annotationen an einem
Haufen zu finden sind.